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@ System and method for distributed computation based upon the movement execution, and 
interaction of processes in a network. 

(§) A disbibuted computing environment in which agent processes direct their own movement through a 
computer network. Place processes provide a computing context within which agent processes are 
interpreted. An agent process controls its movement from one place process to another within the 
network by using a ticket An agent process which moves from one place process to another transports 
definittons of classes of which objects included in the agent process are members. An agent process 
which moves from one place process to a second place process avoids unnecessary transportation of 
objects included in the agent process by substituting equivalent objects which are found in the second 
place process. An agent process sends clones of the agent process to several place processes 
simultaneously, if two clones travel along paths which are coextensive for an initial portion thereof, a 
single done is transported along the initial portion of the paths and other dones are formed from the 
single done, thereby avoiding transferring redundant infomnatton along communicattons media. Two 
agent processes, whteh occupy a single place process, interact by exchanging references to one 
another. The single place process ensures tiiat neither agent process receives a reference to the other 
agent process without simultaneously giving to the other agent process a reference to the former agent 
process. Unauthorized or inadvertent excessive use of networic resources by an agent process, or a 
place process, is prevented by assodating with each process a pennit which defines various capabilities 
and resource allowances of tiie process. 
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CROSS REFERENCE TO APPENDIX E, F AND G 

(copies of which have been filed with this application and form part of US application 08/090.521 which 
was filed at the United States Patent Office on 8 July 1993. 

Appendix E, which is incorporated herein by reference, describes the interchange of objects during the 
movennent of a process through a network in one embodiment of the present invention, which is described more 
completely below. 

Appendix F, which is incorporated herein by reference, describes the transfer of data between computer 
systems interconnected via a network in one embodiment of the present Inventton. 

Appendix G, which is incorporated herein by reference, is a list of computer programs and related data in 
one embodiment of the present invention, which is described rTK>re completely below. 

A portion of the disclosure of this patent document contains material which is subject to copyright protec- 
tion. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or 
the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise 
reserves all copyright rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates to a distributed computing environment and in particular, to an improved distributed 
computing environment wherein processes are created in an object oriented environment and direct their own 
movement throughout a computer network, 

BACKGROUND OF THE INVENTION 

Many different computing systems are available today, but most of these systems are built around funda- 
mental components such as those illustrated in Figure 1. Typically, a computer system 20 includes a central 
processing unit 10 (CPU), which is connected through an input bus 11 to an input module 12 and through an 
output bus 13 to an output nrioduie 14. CPU 10 is also connected through data buses 15, 16 to a memory unit 
17. 

CPU 10 provides control and computing functions. Input and output modules 12, 14 are used to commu- 
nicate between the computer user and CPU 1 0. Input module 12 supplies information to CPU 10. Typical input 
devices are a keyboard and a mouse. Output module 14 displays information from central processing unit 10. 
Typical output modules include video display monitors, printers, plotters and other visual display means. Input 
unit 12 and output unit 14 are frequently referred to as input/output (I/O) units. 

Memory unit 1 7 typically contains two general types of information, instructions and data. A computer pro- 
gram is a sequence of instructions that are executed by the computer to perfonm a specific function. Data in 
memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is 
executing in CPU 10, An executing computer program is called a computer process. 

Menrory unit 17 typically includes mass memory 17A, sometinws called secondary memory, and main 
memory 1 7B. Main memory 1 78 is usually used to store at least a portion of a program currently being executed 
by CPU 10 and data required by the program. Mass menwry 17A. e.g. magnetic disk or tape, is used to store 
programs, data, or porttons of either programs or data which are not needed immediately by CPU 10 or which 
cannot be accomnnodated in nriain memory 17B because of size limitations of main menrwry 17B. 

The operating system of a computer is a computer process which coordinates operation of CPU 10. I/O 
devices 12, 14 and 17A and main menwry 17B and which provides an interface between user applications 
(defined below) and computer hardware. As is used herein, the term computer hardware refers to the physical 
components of the computer system. As an operating system is necessary for the orderly operatton of a con>- 
puter system, the operating system is loaded into main men>ory 1 7B and executed during power up of the com- 
puter system (a process called "booting") and remains in main memory 17B and in execution until the computer 
system is ultin^tely deactivated. 

A user application generally refers to a computer process which executes in addition to. and is generally 
considered distinct from, the operating system. Auser application begins at some point in time as source code, 
i.e., computer instructions in a form intelligible to human t)eings. This source code is translated or "compiled* 
into object code, which is a form intelligible to computer system 20, particularly CPU 1 0. Several object code 
modules may be linked to form a single executable image, which is in a form which can be processed by CPU 
10 of computer system 20. The program is executed by copying the executable image into main memory 17B 
and instructing CPU 10 to carry out the instructions, one by one. of the executable image. As stated above, 
a computer program in such state of execution is called a process. 
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The instructions executed by a process executing within computer system 20 generally manipulate the re- 
sources of computer system 20. For example, instructions can manipulate data stored in mass memory 17A. 
accept data from input nrKxIuie 12 or display data on output module 14. Some processes, which are designed 
to execute on a first computer system, are configured to issue computer instructions which manipulate resourc- 
5 es of a second computer system. 

It is well-known in the art of computer communications to connect two or more computer systems such 
that data can be transferred between two or more computer systems. Two or more computer systems so con- 
nected are collectively called a "network". In such a network, each computer system treats each other com- 
puter system as an I/O device to which data can be sent and from which data can be received. 
10 A first process executing on a first computer system can issue instructions to a second process executing 
on a second computer system. The second process then manipulates the resources of the second computer 
system in accordance with the instructtons received from the first process. The second process Is called a 
•server" process because the second process provides a service to the first process, which is called a "dienr 
process. The service provided is the manipulation of resources of the second computer system. 
15 Many computer communication systems implement what is called "renrwte procedure calling". In remote 

procedure calling, a client process, which is executing on a first computer system and which seeks to manip- 
ulate data on a second computer system, requests action through a server process, which is executing on the 
second computer system and which manipulates data in response to requests from the client process. The 
server process performs any of an inevitably finite list of operations on behalf of the client process. Often it is 
20 the case that the precise function requested by the client process is not among the particular operations per- 
formed by the server process. To perform a function for which no server process operation is defined requires 
several requests to and responses from the server process that require substantial use of communications 
media which in turn involves considerable expense and time. 

Logic flow diagram 200 (Figure 2A) illustrates an example of renrrote procedure calling. Logic flow diagram 
25 200 is described in the context of computer systems 20Aand 20B (Figure 2B), which are interconnected through 
network 256. Suppose a client process 252 on computer system 20A is to delete all files on computer system 
20B whose names match a given pattern, e.g., file names ending in ".TMP", and which have not been modified 
in at least 30 days. Client process 252 sends to server process 254 which is executing on computer system 
208 a request to list all files in step 21 (Figure 2A). Arrow 260 (Figure 28) represents that request Processing 
30 transfers from step 21 (Figure 2A) to step 22 in which client process 252 (Figure 28) receives the list from 
server process 254. as shown as arrow 262. Steps 21 and 22 (Figure 2A) Involve two transfers across network 
communications media. 

Double rectangles in Figures 2A and 3A indicate information transfer across network 256 (Figure 28). 
Whereas execution of an instruction within either computer 20A or computer 208 takes between several nano- 
35 seconds to several microseconds, transfer of infbnmation across network 256 generally takes seconds or min- 
utes depending on the conf iguratton of network 256 and on the amount of infbnmation. In some networks, trans- 
fer of a large amount of data can take an hour or more. 

Processing transfere from step 22 (Figure 2A) to for each filename step 23. For each filename step 23 
and next steps 23a, 23b and 23c define a loop within which each filename of the list of filenames is processed 
by the client process. For each filename of the list, processing transfers from for each filename step 23 to a 
test step 24 in which client process 252 (Figure 28) compares the filename to a pattern. If the filename does 
not match the pattern, processing transfers from test step 24 (Figure 2A) through next step 23a to for each 
filename step 23 and the next filename is processed. 

Conversely, if the filename matches the pattern, processing transfers from test step 24 to step 25. In step 
25. dient process 252 (Figure 28) sends to server process 254 an instruction to provide the date that the par- 
ticular file was last modified as shown by arrow 264. Processing transfers from step 25 (Figure 2A) to step 26 
in which dient process 252 (Figure 28) receives from server process 254 the date requested as represented 
by arrow 266, Steps 25 and 26 (Figure 2A) involve two more transfers across network communications media 
for each such matching filename. 

Processing transfers from step 26 to a second test step 27 in which dient process 252 (Figure 28) com- 
pares the date received with the cun-ent date less 30 days. If the date indicates that the file has been modified 
within the preceding 30 days, processing transfers from second test stop 27 (Figure 2A) through next step 23b 
to for each filename test step 23 in which the next filename is processed. Conversely, if the date indicates 
that the file has not been modified within the preceding 30 days, processing transfers from second test step 
55 27 to step 28. 

In step 28, dient process 252 (Figure 28) sends to server process 254 an instruction directing server proc- 
ess 254 to delete the file from computer system 208 as represented by arrow 268. Processing transfers from 
step 28 to step 29 (Figure 2A), in which dient process 252 (Figure 28) receives from server process 254 ac- 
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knowtedgement of the deletion as represented by arrow 270. Thus, steps 28 and 29 (Figure 2A) involve two 
further transfers across network 256 (Figure 26) for each file to be deleted. 

Processing transfers from step 29 through next step 23C to for each filename step 23. If all filenames in 
the list have been processed, processing transfers from for each filename step 23 to terminal step 20b in which 
5 processing temiinates. Thus, processing according to logic flow diagram 200 (Figure 2A) requires a multitude 
of information transfers across network 256. Such heavy use of network communicattons media is both costly 
and time consuming. 

An alternative approach to remote procedure calling is "remote programming". In remote programming, a 
process, which is called a "client process" and which executes on a first computer system, sends to a server 
10 process executing on the second computer system a list of instructions. The instructions are then carried out 
by the server process effectuating the goal of the client process. The instructions whteh the server process 
Is designed to carry out must have some degree of generality; i.e., the instructions must provide some degree 
of decision-making capabilities. 

Logic flow diagram 300 (Figure 3A) illustrates an example of remote programming. To effectuate the ex- 
15 ample given above with respect to Figures 2A and 2B in a renrrote programming environment, client process 
352 (Figure 3B) in step 31 (Figure 3A) builds a program whose instructions are represented by logic flow di- 
agram 31 -P. Logic flow diagram 31 -P Is described below. 

Processing transfers from step 31 to step 32, in which the program is transferred to computer 30B (Figure 
3B) through network 356 as represented by arrow 358. Processing transfers from step 32 to step 33 (Figure 
20 3A) in which the program is executed within computer 30B. During execution, the program is process 352A 
(Figure 3B) within computer SOB. The instructtons of program 352A are executed according to logic flow dia- 
gram 300. 

In step 31-B (Figure 3A), a list of filenames is created. Processing transfera from step 31 -B to for each 
filename step 31-C. For each filename step 31-C and next steps 31-H. 31-1, and 31-J foon a loop within which 

25 each filename in the list of filenames is processed. For each filename, processing transfers from for each fi- 
lename step 31-C to test step 31-0 in which the filename is compared to a pattern. If the filename does not 
match the pattern, processing transfers from test step 31-D through next step 31-H to for each step 31-C. Con- 
veraely, if the filename matches the pattern, processing transfers from test step 31-D to step 31 -E. 

In step 31-E, process 352A retrieves the date of last modification of the file having the filename. Proc- 

30 essing transfers from step 31-E to a second test step 31-F in which the date is compared to the cun-enl date 
less 30 days. The date of last modification of the file is retrieved from server process 354 (Figure 3B). If the 
date of last modification is more recent than the date of 30 days prior, processing transfers from second test 
step 31-F (Figure 3A} through next step 31-1 to for each filename step 31-C. Convereely, if the date of last 
modification Is prior to the date of 30 days prior, processing transfers from second test step 31-F to step 31- 

35 G. In step 31 -G, the file Is deleted by issuing an appropriate instruction to server process 354 (Figure 3B). 
Processing transfere from step 31-G (Figure 3A) through next step 31-J to for each filename step 31-C. If all 
filenames in the list have t>een processed, processing transfere from for each filename step 31-C to terminal 
step 31-K in which process 352A terminates. As indicated by arrows 360 (Figure 3B), alt interaction between 
process 352Aand server process 354 transpired entirely within computer 30B without use of network 356. 

40 After successful completion of the program, processing transfere from step 33 to step 34 (Figure 3A) in 

which server process 354 (Figure 3B) reports to client process 352 that the program completed successfully 
as represented by arrow 362. Note that this remote programming procedure involves only two uses of network 
communications media: a firetto send the program or list of instructkins to server process 354 as represented 
by anrow 356 and a second to receive from server process 354 notification of successful completion of the 

45 program as represented by arrow 362. Note also that client process 352 was able to request of server process 
354 an operation not explicitly provided by, and perhaps not even anticipated by the developere of, server proc- 
ess 354. 

However, rennote programming encounters the same inefficiencies of renDote procedure calling when a 
computer process seeks to coordinate manipulation of data on two or more computer systems. For example, 

50 a process on computer X may seek to delete all files on computer system Y or computer system Z which have 
the same name, date of last modification and size as any file on computer X. Since server process 354 de- 
scribed above with respect to Figures 3Aand 3B is capable of directly manipulating resources on the computer 
system on which the server process is executing, Le. computer system Y, the server process is unable to co- 
ordinate data management spanning more than one computer system without producing the inefficiencies dis- 

55 cussed above in conjunction with remote process calling. 

An improvement over remote programming is described by C. Daniel Wotfson, et al„ "Intelligent Routers", 
9th International Conference on Distributed Computing Systems at pp. 371-375 (1 989). Wolfson et al. disclosed 
a system wherein a process could move from one computer system to another within a network. The process 
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directed its own movement through the network by issuing an instruction whose execution caused the process 
to be moved. The instruction specified to which computer system the process was to be moved. 

However, the solution In the form disdosed in Wolfson et al. was of limited functionality. Processes were 
required to be configured to comport with the specific requirements of the computer system to which the re- 

5 spective processes moved. Processes were not able to communicate with one another processes instead di- 
rectly stored or directly retrieved data from the mass memory of the computer system within which the respec- 
tive processes were executing. One process could only interact with another process only if both processes 
knew the precise location within mass memory where messages were to be stored and/or retrieved. 

The system disclosed by Wolfson et al. did not provide any security. Thus, to the extent that the Wolfeon 

10 et al. system allowed one process to interact with another process, a malicious process could interfere with 
the execution of a second process. In addition, the set of instructions provided to processes of the system dis- 
closed by Wolfson et al. was very limited; only character string data and numerical data representing real num- 
bers were provided for. 

Another system similar to that disclosed by Wolfson et al. was that described by D. Tsichritzis et aL. "KNOs: 

15 KNowledge Acquisition. Dissemination, and Manipulation Objects'. ACM Trans, on Office Information Svs^ 
tenis. vol. 5. no. 1 . pp. 96-112 (1 987). The system described by Tsichritzis et al. added to the system described 
by Wolfson et al. the generality of object-oriented programming. 

Object-oriented programming organizes data and instructions into "objects" in which data represent the 
"state" of an object and instructions are grouped into tasks or "operations" that the object can "perform". Object- 

20 oriented programming represents a very useful conceptual framework in which problems solved by a computer 
may be more easily reduced to a series of computer instructions. 

Objects created in an object-oriented environment are grouped into classes. Objects of a class have states 
of the same structure and perform the same operations. The system disclosed by Tsichritzis et al. did not pro- 
vide for the mobility of dass definitions; therefore, objects of a given dass created within the environment de- 

25 scribed by Tsichritzis et al. could only travel to those computer systems for which the given dass was defined. 
Additionally, objects in the environment described by Tsichritzis et al. were represented in a form that required 
that the computer systems of the network, within which objects could travel, were homogeneous. 

The system taught by Tsichritzis et al. further described an instruction by which a first process, i.e.. a "head" 
process, could create copies of itself. The copies were called "limbs". Tsichritzis et al. taught that limbs could 

30 be sent to remote computer systenrw at the direction of the head process. However, the limbs were not active; 
the computer instructions of a limb were executed only at the directton of the head process. Directing the ao^ 
tivity of a limb process positioned in a remote computer system required that the head process issue commands 
to the limbs across network communications media, involving considerable time and expense in large net- 
works. 

Further inefficiencies were found in the system taught by Tsichritzis et al. when a small computer, e.g.. a 
personal computer, was connected to a large network through a large computer, e.g., a mainframe computer. 
For example, to send many limbs to various computers of the network, the small computer was required to 
send many identical limbs between the small computer and the large computer. As limbs, which are copies of 
the head process, could be quite large, inefficiencies in such a system could have been quite substantial. 

Tsichritzis et al. taught a system wherein a first process communicated with a second processes by giving 
to the second process a reference to the first process. A reference is data which klentifies an object and which 
grants access to the object identified. As the second process contained a reference to the first process, the 
second process could request that the first process execute specific computer instructtons which were con- 
tained within the f iret process. However, as the first process provided the second process with a reference to 
« the f iret process without simultaneously obtaining a reference to the second process, the second process had 
access to the f iret process and the first process dkt not have reciprocal access to the second process. Such 
a system permitted a "malictous" process, i.e.. a process designed by a malicious programmer or inadvertently 
designed to harm other processes, to gain access to a second process without granting reciprocal access. 
Thus, in spite of the achievements of Wolfson et al. and Tsichristzis et al., neither disdoses a system in 
so which new dasses of objects and processes can be created and can be transported to and processed by com- 
puter systems within the network which do not contain dass definitions for the new classes. Neither does either 
WoHson et al. or Tsichristzis et al. discbse a mechanism for implementing a complex and hierarchical security 
scheme. Furthemrrore. neither Wolfson et al. nor Tsichristzis et al. disdose computer processes which can in- 
teract with one another but which cannot gain access to other processes without granting reciprocal access. 
55 Furthemrrare. neither Wolfson et al. nor Tsichristzis et al. disdose computer processes which can travel to 

several computer systems simultaneously by creating several autonomous clones of a process and transport- 
ing the clones to respective computer systems. The limbs taught by Tsichristzis et al. are not autonomous as 
the computer process controls the actions of limbs at remote computer systems. Furthenmore. neither Wolfson 
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et al. nor Tsichristzis et al. disclose efficient transportation of the clones to the respective computer systems 
in which transportation of redundant information across network communication media is minimized. 

SUMMARY OF THE INVENTION 

According to the principles of this invention, a set of interpreted, object-oriented computer instructions is 
used to create novel computer processes that are executed in a distributed computer system. A particular proc- 
ess that utilizes the set of computer instructions is activated by an engine that Is executing within the distributed 
computer system. The engine interprets and effectuates the instructions of the particular process within the 
10 distributed computer system. 

Each engine in the distributed computer system interprets the instructions that define a process uniformly. 
In other words, the instructions which comprise a process and which are interpreted by a first engine do not 
depend on the particular configuration of the computer system within which the first engine is executing The 
instructions, therefore, can be moved to and interpreted by a second engine, even if the first and second en- 
gines are executing within two separate computer systems whose operating systems and haixiware are other- 
wise generally incompatible. The interpreted instructions are Implemented by using interfaces to communica- 
tion, storage, computing and other subsystems of the computer system within which the engine is executing 
These interfaces, which collectively form part of one embodiment of the present invention, are described in 
Appendbc C, which is a part of this disclosure and is incorporated in its entirety herein by reference. 

Two or more engines are interconnected to form a network. The networic is a universe within which com- 
puter processes of this invention travel. In one embodiment, the networit encompasses computer systems that 
would normally be considered clients of, and not part of, other networks. For example, one embodiment of the 
network of this invention encompasses the workstations which are connected by the networic The term "work- 
statton- is used herein to describe a computer system which is used for purposes other than the transportation 
of information to other computer systems. The engines of this invention are interconnected so that engines 
are capable of moving computer processes among thenrtselves. 

To transport a particular computer process, the computer process is suspended and the execution state 
of the computer process is preserved. The instructions of the computer process, the preserved execution state, 
and objects owned by the computer process are packaged, or -encoded*, to generate a string of data that is 
configured so that the string of data can be transported by all standard means of communication used to form 
a network. In one embodiment, the string of data is transported between engines as specified by the protocol 
described in Appendix D, which is a part of this disclosure and is incorporated herein in its entirety by reference. 

Once transported to a destination computer system of the network, the string of data is decoded to gen- 
erate a computer process within the destination computer system. The decoded computer process Includes 
those objects encoded as described above and has the preserved execution state. The destination computer 
system resumes execution of the computer process. The instructions of the computer process are executed 
by the destinatton computer system to perform complex operattons, including defining, creating and manipu- 
lating data objects and interacting with other computer processes executed by the destination computer sys- 
tem. As computer processes are unifbnmly interpretted throughout the network and are encoded and decoded 
for transport between computer systems, the computer processes of this invention provide a new level of func- 
tionality and versatility in intercomputer communication. 

In one embodiment, two classes built into the set of computer instructions of this invention are an agent 
class and a place class. Instructions formed using the agent dass are interpreted by an engine to form an "agent 
process', sometimes refenred to herein simply as "an agenr An agent is an active object in that an engine 
initiates execution of an agent upon creation of the agent The agent dass provides instructions which enable 
an agent to (1) examine and modify itself, (ii) transport itself from a first place process, which is described more 
completely below, in the network to a second place process in the networic. and (iii) interact with other agents 
found at the second place process. The first and second place processes can execute within two separate corrv 
puter systems of the network. Thus, an agent can travel from a first computer system to a second computer 
so system. 

An agent can contain informatten which is carried with the agent from the first place process to the second 
place process. Additionally, the extensibility, generality and functionality of the set of computer instructions 
discussed more completely below provide tremendous flexibility and control in determining, according to the 
instructions which comprise an agent, how and to what destinatk>n the agent, and the information contained 
55 therein, travels. 

The power of agents is counterbalanced by "permits". A pernnit limits the particular capabilities of a par- 
ticular agent on particular occasions. The permit of an agent specifies which of several of the operations de- 
fined for the agent dass can or cannot be performed by the agent. The pemfiit further limits the amount of 
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processing resources the agent can consume and the time at which the agent expires. Additionally, the permit 
specifies the priority of execution of the agent relative to other agents. 

Instructions formed using the place class are interpreted by an engine to fonm a "place process", some- 
times refen-ed to herein simply as "a place". A place is also an active object and the place dass provides in- 
5 structions which enable a place to examine and modify itself and to serve as a venue for agents and a context 
in which agents can interact. Agents each occupy a respective single place. Additionally, each place can oc- 
cupy a single other place. 

Places provide a degree of privacy and security for agents. For example, an agent, which is configured to 
avoid contact with other agents, can occupy a place which is not generally known to other agents, or which 
10 denies ingress to other agents. Conversely, an agent, which is configured to provide services pubtidy to a large 
number of agents, can occupy a place which is widely known to other agents and which grants ingress to other 
agents. 

Agents cannot interact at a distance; i.e.. no two agents can interact unless both occupy the same place. 
To interact with a second agent occupying a second place, a first agent, which occupies a first place, issues 
15 a command causing the first agent to be transported to the second place as discussed below with respect to 
the "go" operation. While both the first and second agents occupy the second place, the first agent can interact 
with the second agent 

Thus, the processes of this Invention are a novel implementatwn of "remote programming," and not the 
more familiar "remote procedure calling" paradigm. Remote programming improves upon remote procedure 

20 calling by (i) enabling processes to interact without communicating across network communications media and 
(ii) improving the performance of the interactions between processes by eliminating communication across 
network communicattons media which often has high-latency. 

The movement of an agent process, from a first place process in a first computer system to a second place 
process either in the first computer system or in a second computer system is called a trip. The agent initiates 

25 the trip by using a "go" operatran, which is defined in the agent dass. The agent controls the movement either 
through the network or within the computer system by creating and submitting, as an argument to the "go" 
operation, a ticket which defines the trip. In one embodiment the ticket specifies the place to which the agent 
is to travel, the "way" by which the agent is to travel, the amount of time in which the trip must be completed, 
and an indication of the urgency of the trip. i.e.. the priority of the trip relative to other trips by other agents 

30 that may be concurrently scheduled. 

The ticket can identify the destination place by specifying the address, name, dass or any combination 
of the address, name and dass of a place to which the agent is to travel. The destination of the trip is any 
place of the spedfied address, name and/or dass which grants the agent ingress within the lime pemiitted 
by the ticket 

35 In the "go" operation, the agent is moved from a first place to a second place as follows: (i) the agent is 
suspended and the execution state of the first agent is preserved; (Ii) the agent is represented in a standardized 
form, i.e., ah octet string, which includes representation of the agent's preserved execution state; (iii) the stan- 
dardized form is transported from the first place to the second place, potentially involving the transfer of the 
standard form from a first computer to a second computer (iv) the agent at the second place is formed from 

40 the standardized form, induding the executton state represented in the standardized form; and (v) interpretation 
of the agent is resumed, the agent initially having the execution state represented in the standardized form. 

As mentioned above, the set of computer instructions of the present invention is object-oriented. Therefore, 
all objects formed according to the present invention are organized into dasses. All dasses in the present in- 
vention are represented by data objects which can be moved along with an agent Thus, dasses, which are 

45 not defined within a place, can nevertheless be used by an agent travelling to the place simply by the agent 
defining the dasses and transporting the conBsponding class objects to the place. 

Every object in one embodiment of the present invention is owned by a process, i.e., either an agent or a 
place. When an agent travels from a first place to a second place, all objects owned by the agent are effectively 
moved to the second place along with the agent However, as discussed below, objects which are equivalent 

so to objects already occupying the second place are not transported in one embodiment of the present invention. 
In additton to the objects owned by the agent all dass objects defining dasses of which those objects are 
members are moved along with the agent to the second place. A dass object is an object constructed in ac- 
cordance with the set of computer instructions described below and in Appendix A which represents a dass 
of objects. 

55 Thus, if an object owned by an agent travelling to a second place is a member of a dass not defined in 

the second place, the object can still travel with the agent as the agent also carries to the second place dass 
objects defining the dasses of which the object is a member. In the prior art. a process which travelled from 
a first computer to a second computer could only process data objects which belonged to dasses defined on 
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In the present invention, many classes of objects are defined at multiple places and therefore do not n««< 
are made interchangeable In one embodiment of the present invention ^ 
IS tmvS[?o3 ' ^ interchangeable object, which is owned by an agent that 

place of only those class objects defining classes which are not defined within the second place Avoidino un 

Tn reS£Sren?^ th""*"'" °' " whte^ those oJjects K^^^^ 

in one embodiment of the present invention, classes are Identified by citations In a computer networic 

ett'n be'^oTeZ:::,'^''^ ""^^ of thl 7JrdtsUu^ 

ItZn ^Tt T^- u" ^^^^"^ *° ""^"^ ""^ agent processes can travel A 

with one another. Therefore, an instruction requiring use of an object of a f iret class, or the first Self 

the instruction, if the second dass is backward-compatible with the f iret dass 

An agent, occupying a f iret place. Is also capable of creating one or more dones of the aaent and movinn 

TaZe^i^e :sr^rS:rrT °" 

to 3at^and d^in^h. 1' oP^'^'^on "send.- The agent specifies the number of clones 

to be created and defines the corresponding trips by creating one or more tidtets which are supplied as arau 

ments to operation "send^ Each tid<etdefinesatrip to be takenbyarespectivedorSt^^^^^^^^ 
Of tidcets supplied by the agent defines the number of dones created 

an«,S«?tl ^^^"^ " "^'^ ^ " '"'"«"y has the executfon state of the 

agent at the time the done was created. Thus, when the done arrives at a second place, the done oTnJnuM 

i e '^cZSlfll^J^'' ' ^'^^"^ P"^^ the same interface. 

iJeSbvr?!«H „ sf"* operettons. as the head precess. Umb processes did not act except as 

Jre^. ^ '° """P"**' ^y***"™ «t the direction of the head 

the done* FrrimT*."' k « "°t contrelled by the agent which created 

^^^ZZt^Si:^^"^! '' '""'"P*'' «9«"t to arrange a meeting, 

wi^h^ cloTJ^ t ' '^'k"' attempt to intereS 

Sow Whr? r ^3^"' ""^•"P''' '° '"'«™°t ^ith any other agent, as discussed 

f^SSIn^ion « » autonomous the don. occupying the second place can travel to a third place by per 
formanw cooperation -go-without being soinstructed by the agentand even without the consort of the age^ 
As limb processes of the prior art were not active and acted only at the diredion of a head process the 

nliir^K" ^ ""T** """^^ necessarily interacted across network communications media. The 
d!n« oT °'""%P"°' f. dosely related to remote procedure calling. In contrast. 

tu^i^J^T^ °Tt 'H ^'^^'^"'^ the present invention are active and autonomous and embody all 
™c . ^ ^ Therefore, no interadion is required (in fad. no interadion is allowed) 

a^ network communications media. Therefore, the paradigm of the present invention is more dosely re- 
owthe'pltorlft"^™'""''"^" '^''^ represents a significant increase in generality 

Increases in efficiency in one embodiment of the present inventton are realized in performance of operation 
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"send" by deferring doning of an agent as long as possible. For example, a first done and a second done are 
to be sent to a first place and a second place, respectively. Suppose that the agent Is executing within a first 
computer system, that the first place is executing within a second computer system, and that the second place 
is executing within a third computer system. Suppose further that in travelling to the first and second places. 

5 the first and second dones must travel through an engine executing on a fourth computer system. In such a 
case, a single clone is formed and transported to the engine executing within the fourth computer system. Thus, 
only a single done is created within the engine interpreting the original agent thereby saving space within that 
engine and only a single done is transported across network communications media to the fourth computer 
system thereby saving time in transporting dones to the fourth computer system. The engine executing within 

10 the fourth computer system fonms from the single done the first and second dones and transports the first 
and second dones to the first and second places, respectively. 

As an agent can own objects which account for a substantial majority of the size of the agent, e.g., a ras- 
terized graphical image such as a facsimile transmission or digitized sound, avoiding sending several copies 
of such large objects, each copy owned by a respective done, to a single engine saves substantial time and 

15 expense. 

A first agent, occupying a place, can initiate a meeting between the first agent and a second agent occu- 
pying the place. During such a meeting, the first agent can transfer to and receive from the second agent data 
in the form of objects, and the second agent process can transfer to and receive from the first agent data in 
the form of objects. 

20 The present invention represents a significant improvement over a prior art system which teaches the post- 
ing of messages on a virtual bulletin board by a first process. The messages are then "read" by the intended 
recipient procesj. In the prior art system, a first process gives to a second process a reference to the first proc- 
ess by posting the reference on the virtual bulletin board. However, since there is no mechanism for simulta- 
neous exchange of references, the second process has access to the first process before giving to the first 

25 process a reference to the second process. Thus, there is no mechanism to prevent "malicious" processes from 
gaining access to other processes without granting to the other processes access to themselves. 

The present invention represents an improved method of establishing contact between two processes 
such that a first process cannot obtain access to a second process without simultaneously granting to the sec- 
ond process access to the first process. 

30 In one embodiment of the present invention, two agents can interact only if both agents occupy the same 

place and the place is a meeting place, A meeting place is a place that is a member of a class of meeting places, 
which is a subdass of the class of places. A first agent directs that a meeting be arranged between the first 
agent and a second agent by issuing an instruction directing the meeting place to arrange the meeting. The 
issued instruction is called operation "meet**, and the first agent's issuance of the instruction is called "request- 

35 ing a meeting". 

The first agent supplies, as an argument to the instruction, a petition defining the meeting. The petition 
defines the meeting by specifying the second agent as the petitioned agent The second agent is specified 
by specifying the name and/or the dass of the second agent The petition further defines the meeting by spec- 
ifying the amount of time in which the meeting must be arranged or abandoned. 

^ In arranging the meeting, the meeting place supplies to the second agent the name and dass of the first 
agent and indicates that the first agent has issued an instruction requesting a meeting with the second agent 
The second agent examines the name and dass of the first agent and responds to the meeting place either 
accepting or rejecting the meeting with the first agent 

If the meeting is rejected, the first agent is informed that the second agent is not available. If the meeting 

45 is accepted, the meeting place gives to the second agent a reference to the first agent and gives to the first 
agent a reference to the second agent With a reference to the second agent, the first agent (i) can direct the 
second agent to perfonm operations; (ii) can supply to the second agent objects as argunnents; and (ill) can 
receive from the second agent objects as results. As the second agent has a reference to the first agent, the 
second agent has similar capabilities with respect to the first agent 

so Either the first or the second agent can terminate the meeting between the two by issuing an appropriate 
command. The meeting place, in performing an operation "part" in response to the issued command, voids 
any references to the second agent contained within the first agent and voids any references to the first agent 
contained within the second agent thereby terminating interaction between the two agents. 

The present invention represents a significant improvement over the prior art as a first agent cannot gain 

55 access to a second agent unless the second agent agrees or without granting to the second agent access to 
the first agent Additionally, since two agents cannot interact unless both occupy the same meeting place, in- 
termediate levelsof security are available to agents. For example, an agent can protect itself from other agents 
by occupying a meeting place whose location is not widely known by other agents. Inversely, an agent which 

9 
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is designed to be highly visible, may occupy a well-known meeting place. No such mechanism is available in 
the prior art 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

Figure 1 shows the structure of computer systems of the prior art 

Figure 2A is a logic flow diagram of a prior art method using remote procedurB calling. 

Figure 2B shows a prior art network implementing remote procedure calling. 

Figure 3A is a logic flow diagram of a prior art method using remote programming. 
10 Figure 3B shows a prior art network Implementing remote programming. 

Figures 4A and 4B show the movement of an agent process through a network constructed in accordance 
with the present inventbn. 

Figures 5Aand 5B show processes, fonmed in accordance with the principles of the present invention, exe- 
cuting within a computer system. 
15 Figure 5C shows a portion of a dass hierarchy graph in accordance with one embodiment of the present 

invention. 

Figures 6A-6C show the movenwnt of an agent process through a network formed in accordance with the 
present inventton. 

Figures 7A-7E show the movement of dones of an agent process through a network formed in accordance 
20 with an aspect of the present invention. 

Figures 8A-8F illustrate interaction between two agent processes by using operatton "meet". 
Figures 9A-9E illustrate the interrelations of place processes formed in accordance with one aspect of the 
present inventk)n. 

Figure 1 0 shows the structure of a computer network formed in accordance with the principles of the pres- 
25 ent invention. 

Figures 11A and 11B show alternative representattons of the network shown in Figure 10. 
Figure 12 is a diagram illustrating the dass relationships of an agent process in one embodiment of the 
present inventk)n. 

Figures 13Aand 13B illustrate the state of an agent process formed in accordance with the present inven- 
30 tion Immediately before and after, respectively, movement of the agent process within a computer network of 
the present inventton by performance of operation "go". 

Figures 14A-14G are logic flow diagrams which illustrate the steps taken to move an agent process through 
a network in accordance with the present invention by performance of operation "go". 

Figures 15A-15E show the structure of a network fornned In accordance with the present invention and 
35 illustrate the movement of an agent process through the network. 

Figure 16 shows the structure of an agent process including a permit 
Figure 1 7 shows the structure of the permit of Figure 16. 

Figure 18A shows the structure of the ticket of Figure 1 3A induding a teleaddress, a citation, a telename. 
and a way. 

40 Figure 1 SB shows the structure of the way of Figure ISA. 

Figure Id shows the structure of the telename of Figure 18A. 

Figure 20A shows a dictionary formed according to one embodiment of the present invention. 
Figure 20B shows the structure of a finder constructed according to one embodiment of the present in- 
vention. 

4S Figure 21 shows the structure of an encoded agent in accordance with one embodiment of the present 

invention. 

Figures 22A and 22B show the state of an agent process immediately prior to and following, respectively, 
performance of operatfon "entering". 

Figure 22C is a logic flow diagram Illustrating the steps taken in perfomnance of operatton "entering" in 
so accordance with one embodinwnt of the present invention. 

Figures 23A and 23B show a portion of the state of a process imnnediately preceding and following, re- 
spectively, performance of operation "exiting". 

Figures 24A-24C are logic flow diagrams illustrating the steps taken in transporting an agent process 
through a network in accordance with an aspect of the present invention. 
55 Figure 240 shows the structure of a repository of interchanged objects whtoh is used in the steps shown 

in Figures 24A-24C. 

Figure 25 shows a computer network formed in accordance with the principles of the present inventton. 
Figures 26A and 26B show a portton of the state of an agent process immediately prior to and following, 

10 
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respectively, performance of operation "send". 

Figure 26C shows the state of a clone of the agent process immediately following performance of operation 
"send". 

Figures 27A and 27B show the state of a engine process before and after, respectively, fomiation of clones 
5 of an agent process in performance of operation "send". 

Figure 28 shows the computer network of Figure 25 in which clones of the agent process have travelled 
to respective computer systems of the computer network in performance of operation "send". 

Figures 29A-29E show a computer network through which dones of an agent process travel according to 
another aspect of the present inventton referred to as "deferred "cloning". 
10 Figure 30A shows the structure of a send frame Including a nil and a list of tickets. 

Figure 30B shows the structure of an encoded done of an agent process formed in acconJance with an 
aspect of the present invention. 

Figures 31 A and 31 B show the state of a process immediately preceding and following, respectively, per- 
formance of operation "meer. 
IS Figure 32 is a logc flow diagram of the steps taken in performance of operation "meer. 
Figure 33 shows a portion of the state of an agent process induding a set of contacts. 
Figures 34A and 34B show the state of a process immediately preceding and following, respectively, per- 
formance of operation "meeting". 

Figure 35 is a logic flow diagram Illustrating the steps taken in performance of operation "meeting" in ac- 
20 cordance with one emfanxliment of the present invention. 

Figure 36 shows the state of two agent processes which are interacting in accordance with an aspect of 
the present inventk)n. 

Figures 37Aand 37B show a portion of the state of an agent process immediately preceding and following, 
respectively, perfonfnance of operation "parT. 
25 Figure 38 shows the state of the agent processes shown in Figure 36 immediately following performance 

of operation "part". 

Figures 39Ar39F show a portion of the state of a first agent process during interaction with a second agent 
process in accordance with the present Invention. 

Figure 40 is a logic flow diagram illustrating steps taken by the second agent process during the interaction 
30 shown in Figures 39A-39F according to one embodiment of the present invention. 

Figure 41 A shows the structure of a dass def initton in accordance with one aspect of the present invention. 
Figure 41 B shows the structure of a dass object formed in accordance with one embod iment of the present 
Invention. 

Figure 41 C shows the structure of a dass object formed in accordance with a second embodiment of the 
35 present inventksn. 

Figure 42 shows the structure of an interface object formed In accordance with the present inventton. 
Figure 43 shows the structure of a feature def initton induding a set, an identifier, and a boolean. 
Figure 44 shows the structure of an attribute definition induding a constraint and a boolean. 
Figure 45 shows the structure of an operation definition induding a constraint and a list, which in turn In- 
40 dudes a constraint 

Figure 46 shows the structure of a constraint 

Figure 47 shows the structure of an implementation object which indudes two lists and six lexicons. 
Figure 48 shows the structure of a method which includes a procedure and a list, which in turn includes 
an toentifier. 

^ Figure 49 shows the structure of the procedure of Figure 48. 

Figure 50 shows the structure of a citatton which indudes a telename, two integers, and an identifier. 

Figure 51 shows the structures of two dted objects, each of which indudes a respective citation. 

Figure 52A is a logic flow diagram illustrating the steps taken in performance of operation "do". 

Figure 52B shows the structure of a predefined frame which includes an integer and a procedure. 
SO Figure 53 shows the execution state of a process which indudes a stack, which in turn indudes a user 
frame. 

Figure 54 shows the state of the user f ranrw of Figure 53. 

Figures 55A and 55B combine as shown in Figure 55C to form a single logic flow diagram illustrating the 
steps taken in perfonmance of a user-defined operation. 
55 Figure 56A shows the executton state of a process which indudes a stack, which in turn indudes a frame. 

Figure 56B shows the executton state of the process of Figure 56A and a second frame. 

Figure 56C shows the executton state of the process of Figures 56A and 56B. induding the stack, which 
in turn Indudes the f irst-menttoned frame and the second frame. 

11 
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Figure 57 is a logic flow diagram illustrating the steps taken in selecting a feature definition and a method 
from the class hierarchy in accordance with the present invention. 

Figure 58A is a diagram showing the hierarchy of the classes of which a list is a member. 

Figure 58B is a diagram showing the hierarchy of the classes of which dass "List" is a member. 
5 Figure 59 is a logic flow diagram illustrating the steps taken in the initialization of an object 

Figure 60 is a logic flow diagram Illustrating the steps taken in performance of operation "ir. 

Figure 61 is a logic flow diagram illustrating the steps taken in performance of operation "either". 

Figures 62A and 62B show a portion of the execution state of a process immediately preceding and fol- 
lowing, respectively, performance of operation "select*. 
10 Figure 63 is a logk: flow diagram Illustrating the steps taken in performance of operation "selecT. 

Figure 64 shows the state of a predefined frame which represents the dynamic state of a performance of 
operation "selecr. 

Figure 65 Is a logic flow diagram illustrating the steps taken in performance of operation "while". 

Figures 66A and 66B show a portion of the execution state of a process immediately prior to and imme- 
15 diately following, respectively, performance of operation "catch". 

Figure 67 is a logk: flow diagram illustrating the steps takers in performance of operation "catch". 

Figure 68 Is a logic flow diagram illustrating the steps taken in performance of operation "loop". 

Figure 69 shows the structure of a repeat frame which includes an executed object and two integers. 

Figure 70 is a logic flow diagram illustrating the steps taken in performance of operation "repeat". 
20 Figure 71 shows the executton state of a process which includes a stack which in turn contains, from top 

to bottom, a user-defined frame, a predefined frame, a repeat frame, and a second user-defined frame. 

GLOSSARY OF TERMS 

25 "Abstract Class": A class which is abstract has no instances. An abstract dass can have subdasses, and an 
abstract class can define features, methods, and properties which are inherited by the subdasses of the ab- 
stract dass. 

"Agent": An agent is a process which occupies a place and which is mobile, i.e. can move from a first place to 
a second place. 

30 "Arguments"; An argument is an object "consumed" by performance of an operation as input data. In other 
words, an argument is an object transferred from the requester to the responder Immediately prior to perfor- 
mance of the operation by the responder at the request of the requester. 

"Attribute": An attribute is a feature which either retrieves or sets information regarding the internal state of 

an object. Usually the information pertains to the object itself, but sometimes the Information pertains to the 
35 reference by which the object is identified in invoking the attribute. An attribute is a pair of operations in which 

one sets, and the other retrieves, information regarding the internal state of the responder. 

"Authority": An authority is an entity which owns and controls various resources in the network. An example 

of an authority is a user of the network. Authorities are created administratively and cannot be created pro- 

grammatically, i.e., cannot be created at the request of a process. 
40 "Class": A dass defines (i) zero or more properties, wh k:h define the internal states of the members of the dass. 

(il) zero or more methods, which define the internal behavior of the members of the dass. and (iii) zero or nnore 

features, which define the external behavior of the members of the class. 

"Concrete Class": A dass which is concrete can have instances. 

"Engine Place": Every engine contains exactly one engine place which represents the engine itself. 
45 "Engine": An engine is a machine in a computer system which manages objects, primarily processes, and exe- 
cutes instructions. An engine is typically a computer process executing within a computer system in additton 
to an operating system and various user applications. One or more engines can be executing within each conrv 
puter system of a network. Each engine processes at least one place. 

"Exceptton": An exception is an object "thrown" by performance of a feature if the feature fails to be performed 
50 completely and successfully. An exceptton, as the term is used herein, is alternatively a conditton which causes 
such an object to be thrown. The responder is said to "throw" an exception, rather than "produce" an exception, 
because an exception arises from the failure of an operatton and is therefore distinct from a result which is 
produced by a successful operation. The distinction between produdng a result and throwing an exception is 
diBSCribed in nrrore detail below and in Appendix A which is hereby incorporated herein in its entirety by refer- 
55 ence. 

"Feature": A feature is a task that an object can be directed to perform. The task is carried out by a method, 
which includes a set of computer instructions. Performance of a feature is accomplished by execution of the 
computer instructions of the feature's method. A feature is associated with a specific dass of objects, and per- 
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formance of a feature can vary with the specific internal state of the object performing the feature. Features 
are conceptually divided into the two categories: (i) attributes and (ii) operations. 

"Frame": A frame is an object which records the dynamic state of a method implementing a feature during per- 
formance of the feature. A frame is used by an engine to maintain infomriation regarting a method which the 
engine is executing, including information identifying the object performing the feature implemented by the 
method and the particular instruction that is currently executing. 

"Identifier": An identifier is an object which can reference a second object. The texT of an Identifier is a string 
which distinguishes the identifier from other identifiers within a particular scope. The various scopes of iden- 
tifiers are discussed in greater detail in Appendbc A. 

"Implementation": An implementation is a set of computer steps performed in performance of a particular fea- 
ture. An "implementation object" is an object defining the various implementations of the various features of 
a class. 

"Instance": An object is an instance of a class if the object is a member of that dass and is not a member of 
any subclass of that dass. 

15 "Interface": An interface defines a particular attribute or the particular arguments consumed and the result pro- 
duced by performance of a particular operation. An "interface objecT is an object defining the various interfaces 
of the various featured of a class. 

"Member": An object is a member of the dass of which the object is an instance and any superdasses of that 
class. 

20 "Method": A method is a set of computer instructions whose execution constitutes performance of a particular 
feature. A "method objecr is an object defining a method. A method has a dynamic state during performance 
of the method, i.e., execution of the instructions of the method. The dynamic state of a method is represented 
by a frame. 

"Network": All engine places, the computer systems in which the engine places execute and communications 
25 apparatus connecting those computer systems collectively form a network. 

"Object": An object is an element in a computing environment within a computer system. An object has an in- 
ternal state defined by zero or more properties, an internal behavior defined by zero or more methods, and 
an external behavior defined by zero or nrore features. 

"Operation": An operation is a feature for which an interface and implementation is defined. 
"Place": A place is a process which is a locale for zero or more processes. A place can occupy a second place. 
The first-mentioned place is a subplace of the second place, and the second place is a superplace of the first 
place. 

"Primitive": A primitive is an object that can be used in the formation of a procedure or a method, and that there- 
fore can serve as an instruction. 

35 "Process": A process is an object which constitutes an autonomous computation. A process is autonomous be- 
cause a process performs a method without being requested to do so by another object. A process commences 
performance of a central method upon creation of the process, and the process is destroyed upon completion 
of the central method. Every object is owned by exactly one process. Every process is owned by itself. As 
used herein, the tenm "computer process" refers to a series of instructions carried out by a computer system. 

40 which is a more general and well-known definition. 

"Property": A property is an object which represents a part of the internal state of a second object 
"Reference": A reference is a data structure which identifies a particular object. An object in being directed 
to perfomi a feature, is identified by a reference to the object supplied by the requester of the feature. Refer- 
ences are either protected or unprotected. An object cannot be altered or modified using a protected reference 

45 to identify the object 

"Region": A region is one or more engine places within a network which are controlled by a single authority. A 
region is generally distinguished by the dose coordination and management of computer systems which sup- 
port the engine places of the region. The transportation of agents within a region is therefore generally quicker 
and less expensive than transportatton of agents between regions. A reg ton can be. for example, a local area 
so network which is connected to a wWe area network. 

"Requester*: A requester is an object which directs another object i.e. the responder. to perform a feature. 
The requester supplies zero or more objects as input data to the responder of the feature requested and re- 
ceives zero or one object as output data from the responder of the feature. Directing an object to perform a 
feature is alternatively called "requesting" the object to perform the feature. 

"Responder": A responder is an object performing a feature at the direct ton of another object i.e. the requester. 
The responder receives zero or more objects as input data and supplies zero or one object as output data in 
performing the feature. A responder is alternatively called a "responding" object 

"Result": A result is an object "produced" by performance of an operation as output data. In other wortJs. a result 
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is an object transferred from the responder to the requ ester immediately following performance of an operation 
by the responder at the request of the requester. 

"Subclass": A subclass Inherits methods, properties, and/or feature definitions from one or more classes. A 
subclass can define one or more properties, methods, and/or features which are not inherited from any other 
5 class and can reimplement a feature which is Inherited from another class by defining a new implementation 
of the feature. 

"Superclass": The classes from which a subclass inherits properties, methods, and/or features are superclass- 
es of the subclass. 

"Virtual Place": Every place which is not an engine place is a virtual place. 

10 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

According to the principles of this invention, a novel set of computer processes are used to route a particular 
computer process to a selected computer system contained in a plurality of interconnected computer systems 

15 and to execute the particular computer process on the selected computer system. The computer processes of 
this invention are defined, in one embodiment, in terms of object-oriented computer processes. The computer 
processes of this invention include (i) an instruction set that defines the various operations in the process and 
(ii) an engine that interprets the instruction set and controls operation of a central processing unit (CPU) in 
performance of the computer processes^ 

20 As explained more completely below, the particular computer process directs its own nwvement, i.e.. 
transportation, through the computer network by executing an instruction which identifies a destination com- 
puter system within the network and directs that the particular computer process be transported there. While 
executing within the destination computer system, the particular computer process may have access to infor- 
mation which is not available elsewhere in the network. The particular computer process can access that in- 

25 formation and use that information to determine to which other computer systems to travel. As explained more 
completely below, the present invention provides computer processes with a level of nDobility. extensibility and 
generality not found in the prior art 

In remote programming paradigms typically found in the prior art, a computer process does not direct its 
own movement, but is sent from a source computer system to execute within a destination computer system. 

30 If the computer process cannot direct its own movement throughout the network, the computer process cannot 
select further destination computer systems to which to travel on the basis of information obtained by the corrv 
puter process at the destination computer system. Thus, such a computer process must return to the source 
computer system with the information obtained before being sent to a second destination computer system. 
As computer processes of the present invention can direct their own movement through the network, computer 

35 processes of the present invention represent a substantial extension of the traditional remote programming 
paradigm. 

Existing remote programming systems, whteh provide processes which direct their own movement through 
a computer network, lack generality and extensibility. Such systems lack generality in that such systems (i) 
are limited to homogeneous computer networks or (ii) require that a travelling process in a heterogeneous net- 

40 work contain instructions which conform specifically to whichever computer system is executing the process, 
i.e. computer systems to which the travelling process travels. In the present invention, a process travels within 
a heterogeneous computer network and the execution of the instructions of the process is independent of which 
particular computer system within which the process executes, i.e., to which the prt>cess travels. As discussed 
below in greater detail, the computer instructions disclosed below are implemented uniformly by each of the 

46 computer systems of a heterogeneous network. Thus, a process formed in accordance with the present inven- 
tion can travel to any computer system within a heterogeneous computer network and execute there without 
any specific informatfon regarding the nature of the computer system. 

Remote programming systems of the prior art typically lack extensibility in that a process cannot create a 
class of data objects and utilize data objects of that class within computer systems to which the process sub- 

so sequently travels. Many computer processes formed today are "object-oriented". As defined above in the Glos- 
sary of Terms, an object has (i) an internal state defined by a number of properties, (ii) an internal behavror 
defined by a number of methods, and (iii) an external behavior defined by a number of features. The properties, 
methods, and features of a group of objects with like properties, methods, and features are defined by a dass. 
In prior art systems, a process which defines a class cannot use objects of the dass while executing in conv 

55 puter systems to which the process subsequently travels. Transportation of class definitions with travelling 
processes is not feasible or practical in prior art systems because class definitions are not standardized; dass 
definitions are generally very large and complex; and a single process generally uses objects of many dasses. 
Class definitions are not "standardized" in that prior art systems are typically based on existing progrann- 
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ming languages which are not designed with mobile processes In mind. Therefore, dass definitions in a process 
formed using one of these existing programming languages typically rely on Infomiation specific to the com- 
puter system within which the process is created, such as the specific menrK)ry addresses of portions of the 
class definitions. Reliance on such infomiation, which is specific to a particular computer system, makes dass 

5 definitions of prior art systems very difficult to transport to remote computer systems. 

In the present Invention, dasses are represented by dass objects which are part of the disdosed computer 
instruction set A process formed in accordance with the present invention indudes dass objects when trav- 
elling from one computer system to another. Thus, a process can define a dass of object in a first computer 
system, travel to a second computer system, and utilize objects of the dass within the second computer sys- 

10 tem. Unnecessary delay and expense in transporting all dasses utilized by a travelling process are eliminated 
by transporting only those dasses which are not defined within the computer system to which the process trav- 
els. 

Additionally, the present invention provides efficiendes not found in the prior art in transporting several 
clones of a process to several destination computer systems simultaneously. As discussed more completely 
16 below, substantial ef f idencies are realized by deferring creation of one or more denes of the process so long 
as the travel path of one done coincides with the travel path of another done. Clones, and this aspect of the 
present invention, are discussed further below. 

In remote programming systems, two processes share information by a first process giving a second proc- 
ess access to the first process. The first process gives the second process access to the first process without 
simultaneously obtaining access to the second process. In such a situation, the second process is free to in- 
terfere with the execution of the first process without compromising the security of the second process. In the 
present invention, a first process obtains access to a second process and simultaneously gives to the second 
process access to the first process through the cooperation and coordination of a third process. Further se- 
curity Is provided as the second process either accepts or rejects such an exchange with the first process ac^ 
cording to the configuration of the second process. The third process ensures that (i) the second process 
agrees to such an exchange and that (IQ each process gains access to the other process simultaneously such 
that neither process can interfere with the execution of the other process without affoKJing a si milar opportunity 
to the other process. 

A novel computer process of this invention is an agent process. An agent process is a computer process 

30 formed of the computer instructions disdosed below in Appendix A, which is a part of this disdosure and which 
is incorporated herein by reference in its entirety. Agent processes are each interpreted by another novel com- 
puter process of this invention, i.e., an engine, and thereby effectuates the computer instructions disclosed 
below and in Appendix A. The term "Interpreted" is used herein as it is understood in the art; a computer in- 
struction in a series of computer instructions is read and executed by an engine before the next computer in- 

35 struction in the series is read. 

Interpreting, ratherthan compiling, instructions of the disdosed instruction set provides greater generality. 
A first agent can travel from a first computer system to a second computer system and meet with a second 
agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perfonm. 

« Yet another novel computer process of this invention is a place process. Place processes are dispersed 
throughout a computer network. Each agent process "occupies" a respective place process; i.e., a place proc- 
ess is part of the internal state of an agent process and therefore provides a context within which the agent 
process executes. Each agent process can initiate and control the agent process's transportation from a first 
place process to a second place process. "Agenr and "place" as used herein are shorthand terms for "agent 

46 process" and "place process", respectively. 

Figure 4A shows computer networici 00 which indudes computer systenw 120Aand 120B which are con- 
nected by communications link 102AB. Computer system 120Ais executing place 220Aand agent 1 50A. Agent 
1 50A occupies place 220Aas shown in Figure 4A. Computer system 120B is executing place 2208. Hereinafter, 
the statement that an agent or place occupies a particular place should be interpreted as induding a statement 

so that the agent or place is executing within the computer system whk:h contains the particular place. 

Agent 1 50A issues an instruction to computer system 1 20A. In response to the instruction, agent 1 50A is 
transported to a place, e.g. place 220B, spedf ied in the instruction. The instruction is called operation "go", 
and the issuance of the instruction by agent 1 50A is called herein perfomnance of operation "go" by agent 1 50A. 
Upon performance of operation "go" by agent 150A, (i) execution of agent 150A is suspended; (ii) agent 
55 160A is encoded into a standardized form which preserves the executton state of agent 150A; (iii) the stan- 
dardized form of agent 150Ais transported to computer system 120B; (iv) agent 150A. induding the preserved 
executton state, is decoded from the standardized form; and (v) execution of agent 150A is resumed within 
computer system 120B. After performance of operation "go" by agent 150A, agent 150Ano longer occupies 



15 



BNSDOCtD: <EP_0634719A2J_> 



EP 0 634 719 A2 

place 220Aand is no longer executing within computer system 1 20A; instead, agent 150A occupies place 220B 
and is executing within computer system 120B (Figure 4B). By enabling an agent to travel to a remote computer 
system in the midst of the agent's execution, the agent is free to travel to data which the agent is configured 
to access. 

5 A standardized fbnn is a form to which agents are encoded for the transportation of the agent from one 

computer system to another. The standardized form preserves the execution state of the encoded agent such 
that the agent can be decoded at the destination computer system and execution of the agent can resume by 
executing the instruction of the agent which sequentially follows operation "go". Each computer system of the 
network of the present invention can maintain an agent In whatever form is convenient for carrying out the com- 

10 puter instructions included in the agent. However, in transporting an agent from one computer system to an- 
other, each computer system of the network must use the standardized form of an agent during transportation 
much the same way that two people must agree to the vocabulary and syntax of a single language to commu- 
nicate. The nature of the standardized form is discussed in greater detail in Appendices B, C and D, which are 
part of this disclosure, and in Appendices E and F which are incorporated in their entirety herein by reference. 

15 As an agent can direct its own movement i.e., transportation, through the network, means must be pro- 
vided for specifying a number of parameters of a trip from a first computer system to a second computer sys- 
tem. A first parameterof a trip is the place to which the agent is transported, i.e.. the destination of the trip. In 
one embodiment, a trip destination can be specified by name, by class, or by address. An address can be, for 
example, a location within a local area network. 

20 Frequently, two or more pathways exist between a first computer system and a second computer system. 

One pathway may be quick but expensive and another may be time consuming but inexpensive. In such a case, 
no single pathway is always preferred in the transportation of an agent Therefore, a second parameter of a 
trip is the "way" and the "means" for travel of an agent 

In addition, errors in configuring an agent for a trip to a nearby computer system can cause the agent to 

25 be inadvertently transported to distant computer systems at considerable expense to the creator of the agent. 
Therefore, an important parameter of a trip is the amount of time or resources that can be expended in trans- 
porting the agent before the trip is aborted. 

Yet another important consideration in controlling the transportation of agents throughout a network is se- 
curity. For example, if all agents travelling to a particular computer system are granted ingress, the particular 

30 computer system may become overburdened with many processes requiring substantial processing, and 
throughput of the particular computer system can suffer. Therefore, another parameter of a trip is the amount 
of resources the agent requires at the destinatton place. Thus, the agent can be denied ingress to the place if 
the resources required by the agent are more than the place is able or willing to provide. 

In one embodiment, a ticket 1306 (Figure 4A) controls the transportation of agent ISOAand specifies place 

35 220B as the destination place. As shown in Figure 4A. agent 150A contains ticket 1306. Ticket 1306 defines 
the trip taken by agent ISOAfrom place 220Ato place 220B. In one embodiment, ticket 1306 specifies (I) the 
destination place of the trip, (ii) the Vay" or pathway and "means" agent 150A is to take to the destination 
place, (ill) the maximum amount of time within which the trip must be completed before the trip is aborted and 
(iv) the amount of resources agent 1 50A asks to use at the destination place. By specifying the amount of re- 

40 sources agent 1 50A is permitted to use at place 220B, place 220B can detemiine whether agent 1 50A requires 
more resources than place 220B is configured to provide. In such a situation, place 220B can deny ingress to 
agent 150A. Thus, using a ticket as described rTK>re completely below, an agent can completely define a pend- 
ing trip between a f iret place and a second place. 

As discussed above, the prior art process known to the inventors cannot manipulate objects of a class de- 

^ fined only in a prevtously occupied computer system. In other words, if a prior art process defines a class of 
objects and thereafter travels to a destination computer system, the process cannot manipulate objects of the 
class unless the destination computer system contains a deflnitk)n of the identical class or the process defines 
the same class again within the destination computer system. As described in greater detail below, agents of 
the present inventbn. which travel from one place to another, transport definitions of classes which are not 

50 defined within the destination place. Thus, agents of the present invention can define a class within a first com- 
puter system, travel to a second computer system and manipulate objects of the class while executing within 
the second computer system. Agents of the present invention therefore represent a significant improvement 
over the known prior art processes. 

What is also generally lacking in the prior art is a means to implement a complex, multi-level security sys- 
55 tern in a computer network in which computer processes are mobile. One type of security which is afforded 
by the present invention, and which is not suggested by the prior art. is the security afforded by places. As 
discussed in greater detail below, places, by granting or denying ingress to various agents, provide various 
levels of security and several places can be configured to provide multi-level, hierarchical security. 
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To assist in the understanding and visualization of the various aspects and embodiments of the present 
Invention, various representational and relational conventions are used in the drawings. Representational and 
relational conventions used herein are represented in Figures 5A. 5B and 5C. Computer system 120A (Figure 
5A) Is executing place 220A, place 220X. place 220Y, agent 1 50A, agent 150X and agent 1 SOY. Computer sys- 
5 tem 120Aalso contains objects 140A, 140B and 140X in a memory, e.g., mass memory or main memory (nei- 
ther shown), of computer system 1 20A. Agent 1 50A and 1 SOX occupy place 220A; place 220Y occupies place 
220X; and agent 150Y occupies place 220Y. Agent ISOAowns objects 140Aand 140B, and agent 150X owns 
object 140X. The relationships of occupancy and ownership are discussed in greater detail below. Briefly, oc- 
cupancy of places provides various levels and types of security, and ownership determines which objects travel 
10 with an agent which performs operation "go". 

Figure SB is an alternative and equivalent representation of the various relationships represented in, and 
described above with respect to. Figure 5A. While Figure 5A accurately represents, e.g., that agent 150X oc- 
cupies place 220A and contains object 140X. the form of Figure 5A is less suitable for representing more com- 
plex relationships. Therefore, the tree structure of Figure 5B is used In the drawings to represent more complex 
15 relationships in illustrating the various computer instructions of various embodiments of the present invention. 
The tree structure of Figure SB should not be confused with the dass hierarchy tree which is shown in 
part in Figure SC. Figure 5C represents the dass relationships of various items represented in Figures SAand 
SB. Objects 140A, 140B and 140X are members of dass "ObjecT which is represented by dass object 520. 
Membership in a dass is discussed in greater detail In the Glossary of Terms above and is represented by a 
20 dashed line between the class and the object which is a member of the dass. Class object 522 represents 
dass "Process", which is a subdass of dass "Objecr. Places 220X, 220Y and 220A are membere of dass 
"Place", which is a subdass of dass "Process" and is represented by dass object 524. Agents 150A, 150X 
and 1S0Y are members of class "Agent", which is a subdass of dass "Process" and is represented by dass 
object 526. Thus, places 220X, 220Y and 220Aand agents 1S0A. 150X and 1S0Y are all members of dass 
25 "Process" and are therefore computer processes. Objects 140A, 140B and 140X are not membere of dass 
"Process" and are therefore not computer processes. 

When an agent is transported from place to place, objects owned by the agent are transported with the 
agent from place to place. However, transporting an object can consume considerable resources if the object 
is large. In general, time in transporting an agent containing objects from a f iret place executing within a first 
30 computer system to a second place executing within a second computer system is substantially reduced by 
eliminating transportation of objects already at the second place. This is easily demonstrated by considering 
a simple example. Agent 150A (Figure 6A) is executing within computer system 120Aand occupies place 220A 
which is also executing within computer system 120A. Agent ISOAowns objects 140A. 140B and 140C. In this 
embodiment, object MOB has digest 622. Digest 622 Indicates that object 140B is interchangeable and that 
35 any object having a digest equal to digest 622 can be substituted for object 140B. 

Place 220B owns, and therefore contains, objects 624 and 626. Object 624 has digest 628. A process "con- 
tains" all the objects owned by the process and the classes of which the process and the objects owned by 
the process are members. 

In performance of operation "go", as indicated above, agent 1 50A and ail objects contained by agent 1 50A 
^ are represented in a standardized form. However, object 140B is not induded in the standardized form of agent 
1 50A. Instead, a copy of digest 622. I.e.. digest 622-C (Figure 6B), is included in the standardized form of agent 
1 SOA. Agent 1S0A, objects UOAand 140C, and digest 622-C are transported over communications link 1 02AB. 
in the direction of arrow A, to computer system 120B. Object 140B is held within computer system 120A at least 
until it is determined that an equivalent interchangeable object is found within computer system 120B. 
45 At computer system 1 20B (Figure 6C), agent 1 SOA, objects 140A and 140C, and digest 622-C are decoded. 
In decoding agent 150A. computer system 120B recognizes digest 622-C and determines whether an object 
with an equivalent digest occupies place 220B. Object 624 occupying place 220B has digest 628 which is equal 
to digest 622, and is therefore equal to digest 622-C. Since digest 626 is equal to digest 622, objects 140B 
and 624 are interchangeable. Therefore, in decoding agent 1S0A. a copy, e.g., object 624-C, is made of object 
50 624 and substituted within agent ISOAfor interchangeable object 140B. Agent 1S0A therefore owns object 624- 
C. which is a copy of object 624, In lieu of object 140B. Thus, transportation of object 140B to place 220B is 
obviated. Since an equivalent interchangeable object is found within computer system 120B, object 140B can 
be deleted from computer system 120A. Of couree, there are situations in which an equivalent interchanged 
object is not found on computer system 120B. In such a situation, object 140B (Figure SB) is retrieved from 
55 computer 1 20A as described more completely below. 

An agent, occupying a first place, is capable of creating one or more done processes of the agent and 
transporting each done process to a respective place. Thus, in effect an agent is capable of traveling to and 
occupying several places simultaneously. Of course. It is not a single agent that travels simultaneously but 
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rather the dones of the agent 

To travel to and occupy several places simultaneously, an agent issues an instruction which creates mul- 
tiple clones of the agent and causes each clone to travel to a respective place. Each done is an agent, and. 
at the time of a done's creation, the done is identical to the original agent, and therefore includes an execution 
5 state identical to that of the original agent 

For example, agent 1 50A. which occupies place 220A in computer 120A (Figure 7A), issues an instruction 
to computer system 120A which creates clones of agent 150Aand transports the dones to occupy one or more 
places, e.g., place 220B in computer system 120B and place 220C in computer system 120C. which are spe- 
cified in the instruction issued. The instruction is called operation "send", and the issuance of the instruction 
10 by agent 150A is called herein perfonmance of operation "send" by agent 150A. Performance of operation 
"send" by agent ISOAas represented in Figures 7A, 7B, 7C and 7D s controlled, in this embodiment by two 
tickets (not shown) within agent 1 50A. The two tickets control the transportatton of respective dones and spec- 
ify places 220B and 220C as the places to whteh respective dones of agent 150A are to be transported. 

Agents 150A-1 and 150A-2 (Figure 7B) are clones formed from agent 150A. and are identical to agent 
15 150A except that agents 150A-1 and 150A-2 do not occupy place 220A. As described above, even the exe- 
cution states of agents 1 50A-1 and 150A-2 are initially kJentical to the executton state of agent 1 50A. Agents 
1 50A-1 and 150A-2 travel along intercomputer communications link 120ABC (Figure 7C), as described in great- 
er detail below, to respective places 220B and 220C. 

After performance of operatton "send" by agent 1 50A (Figure 7D). agent 1 50A continues to occupy place 
20 220A. Agent 1 50A-1 occupies place 220B, and agent 1 50A-2 occupies place 2200. 

Space in computer system 120Aand time in transporting donesof agent 150A are saved by deferring com- 
plete doning of an agent 1 50A so long as the travel path of one done coinckles with the travel path of another 
clone, i.e., at least two dones have some initial portion of their journey that is coextensive. For example, in 
Figure 7E. both dones of agent 150A must pass through computer system 120Dto reach respective destination 
25 places 220B and 220C. Therefore, only a single done of agent 150A. namely, agent 150A-1, is transported to 
computer system 120D. A second done of agent 150A. namely, agent 150A-2, is fonrned in computer system 
120D from agent 150A-1. Agents 150A-1 and 150A-2 are then transported to respective destination places 
220B and 220C. Thus, only a single done of agent 1 50A is formed in computer system 1 20A and only a single 
clone is transported to computer system 120D saving space in computer system 1 20A and time in transporting 
30 agents 150A-1 and 150A-2 to their respective destinatk>ns. 

Two agents exchange information by participating in a meeting between the two agents. In such a meeting, 
each agent is provided with a reference to the other agent As discussed below, a first agent which possesses 
a reference to a second agent (i) can direct the second agent to take specific actions in accordance with in- 
structions contained with the second agent and (ii) can transfer data to and receive data from the second agent 
35 In one aspect of the present invention, an agent is prevented from Interfering with other agents by requiring 
that no agent be given a reference to a second agent unless the second agent is given a reference to the first- 
mentioned agent In that way, no agent can gain access to a second agent without granting reciprocal access. 

Afiret agent, occupying a place, can initiate a meeting with a second agent occupying that place. During 
such a meeting, the first agent can transfer objects to and receive objects from the second agent and the 
40 second agent can transfer objects to and receive objects from the first agent 

A subdass of class "Place" (Figure 5C) is dass "Meeting Place" (not shown). In the illustrative example 
of Figures 8A-8F, place 220B is a member of dass "Meeting Place" and is therefore a meeting place. Therefore, 
place 220B is sometimes referred to herein as "meeting place 220B". Meeting place 220B (Figure 8A), which 
is executing in computer system 120B, provides a means for agents 150A and 150B. which occupy meeting 
4S place 2208. to communicate and share information in a meeting as indicated by arrows Aand B. Petition 3106 
within agent 150A defines and controls the meeting between agents 150A and 150B. 

Ameeting between agent 150Aand 150B is arranged as illustrated by Figures 8B-8F. Agent 150A (Figure 
8B) issues a firet computer instruction, represented by arrow 851. directing meeting place 220B to arrange a 
meeting between agents 150Aand 150B. The first instruction indudes petition 3106. which contrds the meet- 
so ing, and which specifies that agent 150A wants to meet with agent 150B. On behalf of meeting place 220B 
(Figure 80), the engine issues a second computer instruction, represented by arrow 852, which notifies agent 
150B that agent 150A has issued the first computer instructk>n, and whk:h causes executbn of a number of 
computer instructions within agent 150B to determine whether a meeting between agents ISOAand 150B is 
acceptable. 

^ Upon determination that the meeting between agents 150A and 150B is acceptable (Figure 8D). agent 

150B issues a reply, represented by arrow 853, to the second computer instruction, directing the engine, on 
behalf of meeting place 220B. to proceed in arranging the meeting between agents 150Aand 150B. On behalf 
of meeting place 220B (Figure 8E), the engine conveys to agent 150A a reference to agent 1 SOB, the convey- 
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ancG being represented by arrow 854A, and conveys to agent 1 506 a reference to agent 1 50A. the conveyance 
being represented by arrow 854B. Agent 150A (Figure 8F) interacts with agent 150B using the reference to 
agent 150B, the reference being represented by arrow 855A, and agent 1508 interacts with agent 150A using 
the reference to agent 150A, the reference being represented by arrow 8558. 

5 Two agents cannot participate In a meeting together unless the two agents occupy the same place. A hi- 

erarchy of places provides users of the present invention a mechanism to provide varying levels and types of 
access and security to various agents. The benefit of various levels and types of access and security is dem- 
onstrated by the illustrative example of Figures 9A-9E. 

Figure 9A shows a building 902 having floors 902-1 . 902-2. 902-3, 902-4 and 902-5. Floor 902-3 Is a place 

10 within the place of building 902 and is therefore a subplace of building 902. Figure 98 shows floor 902-3 having 
rooms 902-3-1, 902-3-2. 902-3-3, and 902-3-4. Room 902-3-2 is a place within the place of floor 902-3 and 
is therefore a subplace of floor 902-3. 

The organization of building 902 lends itself to hierarchical security. For example, building 902 can be re- 
stricted to allow only people of a first level of security, e.g., military personnel, to enter. Floor 902-3 can be 

15 further restricted to allow only people of a second (higher) level of security, e.g.. naval personnel, to enter. 
Room 902-3-2 can be still further restricted to allow only people of a third (still higher) level of security, e.g.. 
naval officers, to enter. Floor 902-4 can be restricted independently of floor 902-3, e.g., to allow only air force 
personnel to enter. 

The engine in computer system 120X (Figure 9C) is executing places 220X1 and 220X2. Place 220X1 can 

20 represent, for example, building 902. Places 220X1-1 and 220X1-2, which represent, for example, floors 902- 
4 and 902-3, occupy place 220X1 (Figure 9D) and are therefore subplaces of place 220X1. Conversely, place 
220X1 Is a superplace of places 220X1-1 and 220X1-2. Place 220X1-2-1, which represents, for example, room 
902-3-1 . occupies place 220X1-2 (Figure 9E). Place 220X1-2-1 is therefore a subplace of place 220X1-2. and 
place 220X1-2 Is a superplace of place 220X1-2-1. 

25 In one embodiment of the present invention, two agents can only meet "face-to-face", i.e., when both 
agents occupy the same place. As used herein, an agent "occupies" one place only and does not simultane- 
ously occupy subplaces or superplaces of the place. For example, an agent occupying place 220X1-2 does 
not simultaneously occupy place 220X1 or place 220X1-2-1. Just as a first person in building 902 (Figure 9A) 
cannot communicate face-to-face with a second person on floor 902-3 unless the first person is also on floor 

30 902-3, an agent occupying place 220X1 (Figure 9D) cannot communicate with an agent occupying place 
220X1-2. As a first person on floor 902-3 (Figure 98) cannot communicate face-to-face with a second person 
in room 902-3-2 unless the first person is also in room 902-3-2, an agent occupying place 220X1-2 (Figure 
9E) cannot communicate with an agent occupying place 220X1 -2-1 . 

Such a place hierarchy enables a user of the present invention to restrict access to place 220X1 . to further 

35 restrict access to place 220X1-2 and to restrict access to place 220X1-2-1 further still. Additionally, the security 
hierarchy implemented is not necessarily directly related to the place hierarchy implemented. For example, 
access to place 220X1-2 can be more restrictive than access to a subplace of place 220X1-2. such as place 
220X1-2-1 . The restriction of access to a place is described in greater detail below. Thus, the place hierarchy 
enables a user of the present invention to construct sophisticated security hierarchies in which various agents 

40 are given various levels of access to other agents which occupy certain places, subplaces of those places, 
and subplaces of those subplaces. 

To describe further details of the novel processes described above, a better understanding of the structure 
of the computer systems described above is required. In the embodiment shown in Figure 10. three computer 
systems are connected to form a computer network 1 00. Computer system 1 20A includes CPU 1 1 0A, networic 

45 communications hardware 104A, and memory 117A. Input and output modules corresponding to input module 
1 2 and output module 14 of Figure 1 are omitted for clarity. Additionally, mass memory 1 7A and rmm memory 
1 78 of Figure 1 are combined to form menwry 11 7A. Network communications hardware 1 04A can be any de- 
vice which enables CPU 11 OA to propagate signals across and to receive and interpret signals from the net- 
work. 

50 Within memory 117A are a number of computer processes operating concurrently within CPU 11 OA. Net- 

work manager 130A is a computer process which coordinates data transmission between the various computer 
systems of the computer network. Operating system 131 A is a computer process which coordinates the oper- 
ation of the various components and resources of computer system 120A. For example, operating system 131A 
coordinates the use of components CPU 110A. memory 117A and I/O modules (not shown in Figure 10. see 

55 Figure 1 ). Engine 1 32A is a computer process which interprets computer instructions of an object-oriented conr»- 
puter instruction set of this invention and processes information in the form of objects defined in that object- 
oriented computer instruction set. For example, engine 132A effectuates concurrent execution of place 220A 
(Figure 4A) and agent 150A, both of which are processes constructed of the object-oriented computer instruc- 
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tion set of the present invention. Engine 132Ais not shown in Figure 4A. 

In addition to these processes operating within memory 117A (Figure 10) of computer system 120A. there 
are typically one or more processes which are user applications, e.g. user application 133A. User application 
1 33A can request of engine 132A the creation of and/or manipulation of objects defined within the object-ori- 
5 ented instruction set interpreted by engine 132A. 

Computer systems 120B and 120C are configured similarly to computer system 120A. However, while the 
general structure of computer systems 120A. 120B and 120C are similar, computer systems 120A, 120B and 
120C can be otherwise heterogeneous. 

The computer systems of computer network 100 are connected such that an agent process can be trans- 
10 ported from one computer system to another. Computer systems 120A, 1208 and 120C are connected to form 
a computer network by coupling the respective network communications hardware 104 A, 104B and 104C by 
means of communications links 102AB. 102BC and 102AC. Communications links 102AB. 102BC and 102AC 
can be any means by which data can be conveyed from one network communications hardware, e.g.. network 
communications hardware 104Ato another, e.g., network communications hardware 1048. For exairtple. net- 
15 work communications link 1 02AB can be the public switched telephone network, in which case network com- 
munications hardware 104A and 104B are modems and network managers 130Aand 130B are capable of is- 
suing commands to network communications hardware 104Aand 1048. respectively, to establish and utilize 
communicattons via communications link 102AB i.e., the puWk: switched telephone network. 

Objects constructed of the object-oriented computer instruction set are executed by an engine, e.g., en- 
20 gine 132A (Figure 11A). Engine 132A has a communication infrastructure 132A-CI, a program portion 132A- 
P, and a data portion 132A-D. Data representing the state of the various objects executed by engine 132A. 
e.g., object 140A, are stored in data portbn 132A-D of engine 132A. Data portion 132A-D of engine 132A is 
memory space within nrwmory 117A (Figure 10) reserved as woric space for engine 1 32A and is generally in- 
accessible from the perspective of other processes on computer system 120A, e.g. operating system 131A 
25 and user application 133A. 

As discussed above, an engine effectuates execution of processes and objects. Program portton 132A- 
P'(Figure 11 A) of engine 132A includes computer instructtons which effectuate execution of the objects rep- 
resented in data portion 1 32Ar D. The computer instructions which are combined to form program portion 1 32A- 
P can be of a known computer language. For example, the computer software in Appendix G is a program por- 
30 tion of an engine constructed in accordance with the principles of the present invention and is constructed in 
accordance with the C++ programming language. 

Communicatton infrastructure 132A-CI of engine 132A includes computer instructions which transport 
data between engines dispersed throughout network 100. Many aspects of the communication infrastructure 
of an engine are described in greater detail In Appendbc D. whteh is a part of this disclosure. 
35 Figure 11 B is an alternative and equivalent representation of the computer network of Figure 11 A. 

As indicated by Figure 11 A. engine 132B of computer system 1208 is configured in a manner that is directly 
analogous to the configuratran of engine 132A. 
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Objects within the Network 



As explained more completely betow, places 220A and 220B (Figure 4A), agent 150A, ticket 1306, etc. 
are defined using "objects" according to the principles of this invention. As stated above, objects, which are 
formed according to the computer Instructton set interpreted by engines 132Aand 1328 and which are inter- 
preted by engine 1 32A, are stored in data portion 132A-D (Figure 11 A). For example, object 140A in data portion 
45 132A-D is formed according to the computer instruction set interpreted by engines 132A and 132B and is in- 
terpreted by engine 132A. 

Brief Overview of the Computer Instruction Set of the Present Inventton 

so Each of the novel processes of this invention, and the features needed to define and support the proc- 

esses, are defined by a set of computer instructions that are interpreted by an engine of this invention. The 
computer instructions of the present invention are object-oriented. Therefore, data in the present invention, 
e.g., data which represent agent 150A, are organized into objects, each of which has an internal state and an 
external behavior. An obJecTs properties define the object's internal state and the object's features define the 

55 object's external behavior (see Glossary of Terms above). Each object is an instance of a respective one of a 
number of dassea. 

According to the principles of this inventton. all classes defined in the computer instruction set. except for 
mix-in classes which are described below, are subclasses of a dass "ObjecT, which is described more com- 

20 



BNSDOCID: <EP , _0634719A2 I > 



EP 0 634 719 A2 



pletely in Appendix A. Thus, each class that is descritwd herein and which is not a mix-in dass inherits the 
features and properties of dass "Object". 

In one embodinnent. limited multiple inheritance is implemented using mix-in dasses. "Mix-ins" or "mix-in 
classes" are dasses which are not subdasses of dass "ObjecT. Examples of mix-in dasses. which are de- 
5 scribed below and in Appendbc A, indude mix-in dasses "Executed". "Named" and "Referenced". A non-mix- 
in dass. alternatively called a "flavor" or a flavor dass". can be the immediate subdass of at most one flavor, 
but can be the immediate subdass ofzeroormore mix-in dasses. Amix-in class can be the immediate subdass 
of no class or of another mix-in class. Unless otherwise stated, a dass is a flavor. No cydes in dass hierarchy 
are permitted; i.e.. no dass Is permitted to be both a subdass and a superclass of another dass. 

10 The use of mix-in dasses allows features and properties to be defined once and used across a broad va- 

riety of dasses. For example, mix-in dass "Ordered" defines operations for determining the relative order of 
two objects. Flavor dasses "Assodation". "Citation". "Lisr. "Identifier". "Pattern", "Permit". "Bit", "Boolean", 
"Character". "Number*, "Oder and Time" inherit from mbc-in class "Ordered". Thus, associations, dtationsi 
lists, identifiers, patterns, permits, bits, bodeans. characters, numbers, octets and times have an order rel- 

15 ative to other members of the same dass. For example, in the case of numbers, the number two is "after* the 
number one and is "before" the number three. 

The prindpal dass of objects in the present inventton is the dass of processes. As described above, proc- 
esses are either (i) places which are occupied by other processes, or (ii) agents which can (a) transport them- 
selves from a first place, terminating occupancy of the first place, to occupy a second place and (b) interact 

20 with other agents occupying the same place. 

Agent 150A (Figure 11A) is a process formed in accordance with the computer instruction set of the present 
invention whose execution is carried out by engine 132A. Agent 150A can (i) examine and modify itself, (ii) 
transport itself from a first place in network 1 00 (Figure 1 0) to a second place, and (iii) interact with other agents 
which occupy the second place. 

25 Herein, a process is described as perfomiing an operation that consumes arguments and produces zero 
or one result However, a process, in and of itself, is an object that indude&a collection of instructions, which 
are selected from the instructions described more completely below, and which is interpreted by an engine, 
e.g.. engine 132A which is executing in CPU 110A. The performance of an operation by a process, or any other 
object of the disdosed instruction set, is in actuality the selection of and interpreting of a particular group of 

30 the instructions induded in the process or object. Interpreting the instructions of a process by an engine is 
herein alternatively called "interpreting the process". Thus, when agent 150Aperfonms an operation, agent 
150A provides instructions to engine 132A which in turn interprets the instructions and directs CPU 11 OA to 
carry out appropriate tasks effectuating performance of the operation by agent 150A. The interaction between 
a process and an engine is described nrK>re completely below. 

35 An Important aspect of the present invention is that the set of computer instructions described more com- 
pletely below is implemented uniformly by the respective computer systems of network 100 (Figure 10). Com- 
puter systems 120A, 120B and 120C can use completely different and incompatible data structures, memory 
configurations, CPUs and operating systems. But, since an agent is capable of transporting itself to and from 
any of computer systems 120A, 120B and 120C, it is important that each computer system implement the set 

40 of computer instructfons of the present invention in a standardized fashion. As long as the computer instruc- 
tions are uniformly implemented, computer systems 120A, 120B and 120C can be otherwise Incompatible. 
Therefore, agents can travel freely among the computer systems of a heterogeneous, as well as a honwge- 
neous, computer network. 

Typically, prior art systenw either required that processes travel only within homogeneous networks or that 
45 processes be specifically designed to execute computer instructions which were compatible with the computer 
system within which the process was executing. In the latter case, processes were configured for the particular 
system requirements of the computer system on which execution of the process began and for the particular 
system requirements of any computer systems to which the process was intended to travel. Thus, as the com- 
puter instructions of an agent of the present inventron can execute on any computer system of a heterogeneous 
so network, the present invention represents a substantial improvement over the prior art. 

Agents 

As discussed above, the behavior of an agent is dependent in part on the internal state of the agent. There- 
55 fore, prior to considering the external behavior of an agent in a network, several aspects of the internal state 
of an agent are briefly discussed. Each agent is a member of dass "Agenr. 

It should be noted that no agents are instances of dass "Agent," as class "Agenr is abstract Class "Agent" 
is abstract as no implementation for operatton "live" is defined or inherited by dass "Agenf. As discussed below 
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and in Appendix A in greater detail, operation "live" defines the steps that are performed by a process, i.e., an 
agent or a place, upon creation of the process. These steps are collectively called the "central procedure" of 
the process. A central procedure for either agents or places is not provided as users of the present invention 
design and provide central procedures for agents and places to suit the particular needs of each user. Thus. 
5 users of the present invention create concrete subclasses of class "Agenr and therein provide implementations 
for operation "live". 

Class "Agent" is a subclass of class "Process". (See Figure 5.) Class "Process" is a subdass of dass "Ob- 
jecr and also inherits from mbc-in dass "Named". Class "ObjecT inherits from mbc-in dass "Referenced". An 
agent possesses the following attributes: (i) attributes "dass" and "size" inherited from superdass "ObjecT; 
10 (ii) attribute "isProtected" Inherited from mix-in dass "Referenced"; (ill) attribute "name" inherited from mix-In 
class "Named"; and (iv) attributes "brand", "permir and "privateClasses" inherited from superclass "Process". 
Class "Agent" defines no attributes. Each of the above-mentioned attributes and dasses is discussed in more 
detail in Appendix A. 

Diagram 1270 (Figure 12) illustrates the dass relations of the classes of which agent ISOAis a member. 
15 Agent 150A s a member of class "Agent" as agent 150A is shown to be contained within domain 1272 which 
represents dass "AgenT. Since dass "Agenr is abstract, agent 150A is also a member of one or more sub- 
classes (not shown) of dass "Agenr. 

Donmin 1272 is completely contained within domain 1274 which represents dass "Process". Agent 150A 
therefore inherits attributes "brand", "permit" and "privateClasses", which are defined by dass "Process". Ad- 
20 ditionally, all members of dass "Agenr are also members of dass "Process". Thus, as described above, dass 
"Agenr is a subdass of class "Process". 

Domain 1274 e completely contained within domain 1276 which represents class "Objecr. Agent 150A 
therefore inherits attributes "dass" and "size" which are defined by dass "Objecr. Additionally, all membere 
of dass "Process", including members of dass "Agenr, are also members of class "ObjecT. Thus, as described 
25 above, dass "Process" is a subdass of dass "Object". 

Domain 1274 representing dass "Process" is contained within domain 1278. which represents dass 
"Named". Connection 1278A shows that domain 1274 is contained within domain 1278 while accurately rep- 
resenting that domain 1276, representing dass "Objecr, is not contained within domain 1278 and that domain 
1278 is not contained within domain 1276. Class "Named", represented by domain 1278, is a mix-in dass. As 
30 domain 1274 is contained within domain 1278. agent 150A is contained within domain 1278 and is therefore 
a member of mix-in dass "Named". Mbc-in dass "Named" defines attribute "name" which is induded in agent 
150A. 

Domain 1280 which represents mix-in dass "Referenced" contains domain 1276. which represents dass 
"Objecr. as indicated by connection 1280A. As domain 1276 is contained within domain 1280, agent 150A is 
35 contained within domain 1280 and Is therefore a member of mix-in dass "Referenced". Mix-in dass "Refer- 
enced" defines attribute "isProtected" which is Induded In agent 150A. 

As every flavor of the disdosed embodiment of the present invention Is a subdass of dass "Objecr. every 
flavor is also a subdass of mix-in dass "Referenced". Thus, it is not necessary to separata the features of dass 
"Referenced" from the features of dass "Objecr. However, the features of mix-in dass "Referenced" are sepa- 
40 rated from the features of dass "ObjecT to aid conceptualization and understanding of the present invention. 

As discussed above in the Glossary of Terms, objects are identified within the disdosed computer instruc- 
tion set by references. As discussed in greater detail below, in directing an object to perform an operation, the 
object is identified by a reference. Features defined by mix-in dass "Referenced" operate on the reference 
which identifies the object For example, attribute "isProtected" detenmines whether the reference to the object, 
45 and not the object itself, is protected. Features defined by dass "ObjecT operate on the object identified by 
the reference. For example, attribute "class" determines of which dass the object is an instance. 

It should be noted that no attribute is defined which provides information regarding the place occupied by 
agent 1 50A (Figure 1 2). However, the place occupied by agent 1 50A is maintained as a property of agent 1 50A. 
Agent 1 50A can determine which place agent 150A occupies by execution of the "here" selector. The execution 
50 of selectors, and in particular the "here" selector, is discussed in greater detail in Appenda A. The property 
which is the place occupied by agent ISOAis defined by dass "Process". Thus, any process. I.e.. either a place 
or an agent, indudes a property which is the place occupied by the process. 

While the only class disdosed herein and in Appendix A which is an immediate subdass of mix-in dass 
"Named" is dass "Process", subdasses of mix-in dass "Named", which are not subclasses of dass "Process", 
55 are defined by users of the present invention using the instructions disclosed herein and in Appendix A. There- 
fore, dass "Nanrwd" is a mix-in dass. 



22 



BNSDOCID: <EP 063471 9A2 I > 



EP 0 634 710 A2 



Agents as Processes 

Associated with every process, both agents and places, is a central procedure which defines the primary 
behavior of the process as discussed above. The central procedure of a process is the method which imple- 
5 ments an operation "live" as performed by the process. An engine initiates processing of a process by causing 
the process to perform operation "live", thereby causing execution of the process's central procedure. The pro- 
vision of a method for an operation is discussed in greater detail below. When a process completes perfor- 
mance of operation "live", either successfully or otherwise, the process is terminated. The termination of a proc- 
ess is discussed in sectton 2.4.11 of Appendix A and that discussion is incorporated herein by reference. 

10 

Mobility of Agents: Operation "Go* 

As discussed above, an agent travels from one place to another by performance of operation "go". Oper- 
ation "go" is discussed in the context of the illustrative example of Figures 15A-15E. To travel from place 220A 
15 to place 220B, agent 1 50A (Figure 1 5A) perfomrw operation "go". Figure 1 5A shows the state of network 1 500 
prior to performance of operation "go" by agent 150A. 

Agent ISOAowns objects UOAand 140B and occupies place 220Ain engine 132A. Thus, agent 150Aand 
place 220A are processes which are simultaneously interpreted by engine 132A. In other words, place 220A 
and agent ISOAare simultaneously performing operation "live". Engine 132B interprets place 220B and agent 
20 150B. Agent 1 SOB occupies place 220B. 

Communication infrastructure 132A-CI of engine 132A is connected to communication infrastructure 
1322-CI of engine 132Z by communications link 102AZ. Engine 132Z interprets place 220Z. Communication 
infrastructure 132Z-CI is also connected to conrununication infrastructure 132B-CI of engine 132B by commu- 
nications link 102ZB. While in this embodiment only three computer systems are illustrated in network 1500, 
25 the number of computer systems in network 1 500 is an arbitrary number. Hence, the computer systems illu- 
strated in Figure ISA are illustrative of the principles of the invention and are not intended to limit the invention 
to the particular network illustrated. 

Performance of operation "go" by agent 1S0A. in this embodiment, requires transportation of agent 150A 
from engine 132A through engine 132Z to engine 132B. Hence, operation "go" requires action on the part of 
30 engine 1 32A. i.e.. the source engine, engine 1 322, i.e. the transit engine, and engine 1 32B. i.e.. the destination 
engine. 

Operation "Go" as Performed by the Engine Processing the Souroe Place 

35 Figure 13A shows a portion of the internal state, including a portion of the execution state, of agent 150A 
immediately prior to performance of operation "go" by agent 150A. The executfon state of a process is descri- 
bed in greater detail below. Stack 1 304 is a part of the execution state of agent 150A. Stack 1304 contains, at 
top "T", ticket 1306. Ticket 1306 is described more completely below. Arguments consumed by performance 
of operation "go" are popped from stack 1304 and stack 1304 is therefore the "current stack" in the context of 

40 operation "go". Place 220A is a property of agent 1 SOA. indicating that agent 1 50A occupies place 220A. 

Figure 13B shows a portion of the internal state, including a portton of the execution state, of agent 150A 
immediately following performance of operation "go" by agent 150A. Figure 13B is described in greater detail 
below. 

Logic flow diagram 1 400 (Figure 1 4A) illustrates operation "go" as carried out by engine 1 32A (Figure 1 SA). 

46 Engine 132A is the source engine as agent 160A is executing within engine 1 32A when performance of oper- 
atton "go" is initiated. The steps of logic flow diagram 1400 (Figure 14A) are discussed in the context of the 
trip from place 220A (Figure ISA) to place 220B taken by agent 150A. 

In performance of operation "go" by agent 150A. engine 1 32A (Figure 15A) determines wh ether agent 150A 
is the agent requesting performance of operation "go" in an access test step 1402 (Figure 14A). If operation 

so -go" is requested by an object other than agent 1 SOA (Figure 1 SA), processing transfers from access test step 
1 402 (Figure 14A) to terminal step 1404 in which an exception of dass "Process Not Current" is thrown causing 
operation "go" to fail. If. however, operatton "go" is requested by agent 150A(Figure ISA), processing transfere 
from access test step 1402 (Figure 14A) to a "canGo" test step 1406. 

In "canGo" test step 1406. engine 1 32A (Figure ISA) determines whether agent 150A is permitted to per- 

55 form operation "go". In "canGo" test step 1406. engine 132A (Figure ISA), queries attribute "permir of agent 
1 SOA. Attribute "permir as discussed above, is one of a plurality of attributes of agent 150A. The various at- 
tributes of agent 1S0A are described in greater detail in Appendbc A in conjunction with dass "Process". The 
query of attribute "penfnit" of agent 1 SOA produces property "permit" of agent 150A. Spedfically. permit 1612 
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(Figure 16) is property •permit" of agent 150Aand is therefore produced by querying attribute 'permir of agent 
1 50A. In tliis embodiment, property "penfnif is one of a number of properties of agent 1 50A. 

Permit 1612 (Figure 17) includes, among several properties which are described in greater detail in Ap- 
pendix A. properties "charges", "canGo", and "age" which are integer 1702, boolean 1704. and Integer 1706, 

5 respectively. A boolean is an object having one of only two possible values: "true" or "false". In "canGo" test 
step 1406 (Figure 14A). engine 132A(Figure 15A) queries attribute "canGo" of pennit 1612 (Figure 17). thereby 
producing boolean 1704 which is property "canGo" of permit 1612. and compares boolean 1704 to "true". 

If boolean 1704 has a value of "false", processing transfers from "canGo" test step 1406 (Figure 14A) to 
terminal step 1408. Agent 150A is not penmitted to travel by performance of operation "go" and the operation 

10 falls and throws an exception that is a member of dass "Penmit Violated" in terminal step 1408. Exceptions 
and their classification are described more completely in Appendbc A. 

Otherwise, if boolean 1704 (Figure 17) has a value of "true", processing transfers from "canGo" test step 
1406 (Figure 14A) to an effectuate move step 1410. Effectuate move step 1410 is described in greater detail 
below in conjunction with Figure 14B. Processing transfers from effectuate move step 1410 (Figure 14A) to 

IS terminal step 1412 in which operation "go", to the extent engine 132A is involved, completes successfully. 

Effectuate move step 1410. which is performed by engine 132A (Figure 15A) as described above, is rep- 
resented by logic flow diagram 1410 (Figure 14B). In the first step of logic flow diagram 1410, i.e.. route agent 
step 1414. engine 132A(Figure 15A) selects an engine to use in transporting agent 150A to the trip destination, 
i.e.. a "transfer destination". As used herein, the transfer destination is the next engine used in the trip and 

20 should not be confused with the "trip destination". Ticket 1 306 (Figure 1 3A) defines a place as the destination 
of a trip; therefore, the "trip destination" is a place. In the course of the trip defined by ticket 1306 (Figure 13A). 
agent 150A (Figure 15A) is transfen-ed from one engine to another. Therefore, a "transfer destination" is an 
engine. In general, a trip can require several transfers of an agent before the agent reaches an engine which 
contains a trip destinatton. 

25 In step 1414 (Figure 14B), a way object, i.e., a member of dass "Wa/, which defines a transfer destination 
is produced. The transfer destination can be, for example, (i) the engine which cun-ently contains agent 1 50A, 
i.e., engine 132A, in which case agent 150A is not transfenred, (ii) another engine in the region which contains 
engine 132A. or (iii) an engine in another region. In either of possibilities (ii) or (ill), agent 150A is transferred 
to the transfer destination as described below. 

30 The term "region" is defined above in the Glossary of Tenms. The grouping of engines into regions is sig- 
nificant in the routing of an agent as each engine typically contains more detailed information regarding other 
engines within the same region than engines of other regions. This is true because engines of a single region 
are configured by a single person or organization, which is therefore called the "provider" of the region. There- 
fore, each engine of a region can be given detailed information regarding other engines of the region as all 

35 such engines are provkled by a single provider. 

The grouping of engines into regions is helpful in routing agents in targe and complex networks. When an 
agent travels between regtons, it is not imperative that the source engine contain any informatron regarding 
the transfer destination engine. It is sufficient that the source engine can determine to which region the agent 
is traveling and can transfer the agent to an engine in that region. Once transferred to an engine in the region 

^ containing the place that is the trip destination, the agent can be more easily routed to an engine containing 
that place. 

Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 1414 (Figure 148) 
and is discussed below in greater detail. 

Processing transfers from route agent step 1414 to an isolate agent step 1416 where agent 150A (Figure 
46 1 5A) is isolated. Isolation of a process is described in greater detail In Appendbc A and that discussion is incor- 
porated herein by reference. Briefly, agent 150A is isolated (i) by voiding all references within agent 150A to 
other processes, and to objects owned by other processes, and (ii) by voiding within all other processes ref- 
erences to agent 1 50A and to objects owned by agent 1 50A. Processing transfers from isolate agent step 1416 
(Figure 14B) to exiting step 1418. 
so In exiting step 1418. place 220A (Figure 1 5A) notes the departure of agent 1 50A by performing operation 

"exiting" at the request of engine 132A. Operatk>n "exiting" is described below in greater detail. Processing 
transfers from exiting step 1418 to a next hop is here test step 1420. 

In next hop is here test step 1420. engine 132A (Figure 15A) compares the transfer destination determined 
in route agent step 1414 (Figure 14B) to the current engine, i.e., engine 1 32A (Figure 1 5A). If the transfer des- 
55 tination is the current engine, i.e., engine 1 32A, processing transfers from next hop is here test step 1 420 (Fig- 
ure 148) to deliver agent step 1422. In the illustrative example of Figures 15A-15E. agent 150A is transferred 
to engine 1 32Z. as discussed below; thus, the transfer destination is not the current engine, i.e.. engine 1 32A, 
. and processing does not transfer to deliver agent step 1422 (Figure 148). However, deliver agent step 1422 
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and the steps which fotlow are described for completeness. 

In deliver agent step 1422. agent 150A (Figure 15A) is delivered to a place within engine 132A which sat- 
isfies ticket 1 306 (Figure 1 3A). Deliver agent step 1422 (Figure 14B) is represented by logic flow diagram 1422 
(Figure 14E) and is discussed In greater detail below. Processing transfers from deliver agent step 1422 (Figure 

5 14B) to a first exception test step 1424 in which engine 132A (Figure 1 5A) determines whether delivery of agent 
1 50A threw an exception. If no exception is thrown in deliver agent step 1422 (Figure 14B). processing transfers 
from first exception test step 1424 to terminal step 1428. Terminal step 1428 completes move step 1410 and 
so processing transfers to terminal step 1412 (Figure 14A) wtiich is described above. 

If, on the other hand, an exception is thrown in deliver agent step 1422 (Figure 14B), processing transfers 

10 from first exception test step 1424 to step 1426 In which agent 150A is delivered to purgatory according to 
logic flow diagram 1422 (Figure 1 4E). Purgatory is a place within each engine and which never denies ingress 
to a process. In entering purgatory, the local permit of agent 150A can be severely restricted. For example, 
property "canGo" of the local permit is set to "true" and properties "canCharge". "canCreate", "canDeny". "can- 
Grant", "canRestart", "canSend" and "canTenminate" are set to "false". Properties "charges" and "age" are set 

15 just large enough that agent 150A can detect and analyze the exception that sent agent 150A to purgatory, 
and can travel to another place by performance of operation "go". The various properties of a permit are de- 
scribed in greater detail in Appendix A. 

Processing transfera from step 1426 to terminal step 1 428 and so effectuate move step 1410 (Figure 14A), 
completes successfully, as described above. 

20 As discussed above, if the transfer destination detemiined in route agent step 1414 (Figure 14B) is the 
cunrent engine, i.e., engine 132A, processing transfers from next hop is here test step 1420 (Figure 14B) to 
deliver agent step 1422. Conversely, if the transfer destination is not the current engine, processing transfers 
from next hop is here test step 1 420 to a form destination step 1 430. In fonm destination step 1 430, a destination 
object which specifies the transfer destination is fonmed. Processing transfers from fonm destination step 1430 

25 . to encode agent step 1432. 

In encode agent step 1432, engine 132A (Figure ISA) encodes agent 1 50A according to the encoding rules 
of the Telescript Encoding Rules, included as Appendbc B, which is a part of this disclosure and which is incor- 
porated herein by reference in its entirety. Encoding agent 1 50A results in (i) agent 1 50A, (ii) all objects owned 
by agent 150A including objects 140Aand 140B and (iii) the classes of which agent 150Aand all objects owned 

30 by agent ISOAare members being represented in encoded agent 150A-E (Figure 15B) in a standardized binary 
form. The destination object formed in fonm destination step 1430 (Figure 14B). i.e.. destination object 150A- 
E-D (Figure 21), is included in encoded agent 150A-E and is discussed in greater detail below. As shown in 
Figure 15B. encoded agent 150A-E is stored in communication infrastructure 132A-CI of engine 132A. Agent 
1 50A (Figure 1 5A) is retained by engine 1 32A until the transfer of encoded agent 1 50A-E is complete as de- 

35 scribed below In greater detail. 

Processing transfera from encode agent step 1432 to transfer out step 1434. In transfer out step 1434. 
engine 132A (Figure 1 5B) initiates transfer of encoded agent 1 50A-E according to the destination object fonned 
in form destination step 1430 (Figure 14B). In this example, the destination object specif ies engine 1322 (Fig- 
ure 1 SB) as the transfer destination of encoded agent 1 50A-E. Encoded agent 1 50A-E is transferred as ordi- 

^ nary binary data from communications infrastructure 132A-CI, across communications link 102AZ, to com- 
munications infrastructure 132Z-C1 of engine 132Z. The transportation of data between communications in- 
frastructures 132A-CI and 132Z-CI is described in greater detail in Appendix C which is a part of this disclosure 
and Appendix F which is incorporated herein in its entirety by reference. As discussed above, the transfer of 
encoded agent 150A-E is initiated in transfer agent outstep 1434. Processing according to logic flow diagram 

45 1410 (Figure 148) by program portion 132A-P of engine 132A proceeds while the transfer of encoded agent 
1S0A-E between communications infrastructures 132A-CI and 132Z-CI continues. 

Processing transfera from transfer out step 1434 to a second exceptk>n test step 1436 in which engine 
132A determines whether transfer out step 1434 threw an exception, i.e.. whether initiation of the transfer of 
encoded agent 150A-E failed. If transfer out step 1434 fails, processing transfers from second exception test 

so step 1426 in which agent 150A is delivered to purgatory as described above. Conversely, if transfer out step 
1434 succeeds, processing transfera from second exception test step 1436 to step 1438. 

In step 1438, engine 132A (Figure 15B) adds agent 150A to a list of pending transfera. Agent 132A is re- 
tained in the list of pending transfera during the transfer of agent 150A. When the transfer is complete, agent 
1 50A is removed from the list of pending transfera and discarded by engine 1 32A. If the permit of agent 150A 
55 expires while agent 150A is still on the list of pending transfera, i.e., if the actual age of agent 1 50A reaches 
property "age" of the effective penmit of agent 1 SOA, the transfer of encoded agent 1 50A-E is aborted; agent 
1 SOA is removed from the list of pending transfera; and agent 1S0A throws an exception of class "Permit Ex- 
pired", thereby falling to perform operation "go" successfully. The "effective pemnit" of a process is described 
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in greater detail in Appendix A. Processing transfers from step 1438 to tenminal step 1428 in which logic flow 
diagram 1410 (Figure 14B), and therefore effectuate nfK>ve step 1410 (Figure 14A), completes. 

As described above, in route agent step 1414, engine 132A (Figure 15A) determines the transfer destin- 
ation for agent 150A. Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 
5 1414 (Figure 14B). 

The following discussion of logic flow diagram 1414 (Figures 14C and 14D) considers circumstances be- 
yond the scope of the illustrative example of Figures 15A-1 5E. Logic flow diagram 1414 (Figures 14C and 14D) 
is therefore described Independently of the illustrative example of Figures 15A-15E. To provide a framework 
for discussion, however, logic flow diagram 1414 (Figures 14C and 14D) is described in the context of agent 
10 1 50A (Figure 1 5A) performing operation "go" to effectuate a trip which originates in place 220A within engine 
1 32A. The discussion of logic flow diagram 1414 (Figures 14C and 14D) is not limited to (i) a trip in which agent 
1 50A is transferred to an engine other than engine 132A (Figure 1 5A) or (ii) a network in which engines 1 32A, 
1 322 and 132B are of the same region. Furthermore, the following discussion does not limit ticket 1306 (Figure 
13A). which defines the trip taken by agent 150A (Figure 15A). to either including or excluding specification 
15 Of a way, a means, a telename, or a provider. Ticket 1306 (Figure 13A), in the context of logic flow diagram 
1414 (Figures 14C and 14D). can define a trip (i) to a place within engine 132A (Figure 15A). (ii) to a place 
within an engine in the same region as engine 132A, or (lii) to a place within an engine in a region different 
than the region whksh contains engine 132A. 

Recall that for operation "go", ticket 1 306. which is consumed as an argument to operation "go", specifies 
20 the destination and other characteristics of the trip. In togic flow diagram 1414, engine 132A (Figure 15A) in 
test step 1440 queries attribute "way" of ticket 1306 (Figures 13 and ISA), thereby producing property "way" 
of ticket 1306. Property "way" of ticket 1306 is way 1820 (Figure 18A). Property Vay" of ticket 1306 is optional 
and can therefore alternatively be a nil (not shown). 

If property "way" of ticket 1306 is a nil. processing transfers from test step 1440 to a ticket has provider 
25 test step 1460 which is described below in greater detail. Conversely, if property "way" of ticket 1306 is a way. 
i.e.. is not a nil. processing transfers from test step 1440 to step 1442 in which engine 1 32A (Figure 15A) queries 
attribute "name" of way 1820 (Figure 18A). thereby producing the telename that is property "name" of way 
1820. Also in step 1442 (Figure 14C). engine 132A (Figure 15A) produces and copies property "authority" of 
that telename. The resulting "authority", which is represented by an octet string as described in Appendix A, 
30 is used to determine the transfer destination, as described below. 

Processing transfere from step 1442 to a way has means test step 1444 (Figure 14C) in which attribute 
"means" of way 1 820 (Figure 1 88) is queried, thereby producing property "means" of way 1 820. which is means 
object 1822. Property "means" is optional and can therefore alternatively be a nil (not shown). 

A means object. I.e., a member of class "Means", is an object which specifies an engine by specifying (I) 
35 an intercomputer communications medium and (ii) transfer instructions to reach a specific engine via that me- 
dium. For example, a means object can specify the public switched telephone network (PSTN) and specify 
modem instructions which include the telephone number of a specific modem through which to transfer the 
agent to a destinatton engine. As a means object contains all information needed to route agent 1 50A to a des- 
tination engine, other properties of ticket 1306 are ignored if ticket 1306 contains a means object 
^ Therefore. If property "means" of way 1820 is not nil, i.e., is means object 1822 (Figure 188), processing 
transfers from way has means test step 1444 (Figure 14C) to step 1446. In step 1446. way 1 820 is designated 
as the way which defines the transfer destination. It should be noted that means object 1 822 defines the engine 
that is the destination of the first hop, i.e., the f iret transfer of agent 1 50A (Figure 1 5A), and not the destination 
of the trip defined by ticket 1 306 (Figure 1 8A), which is necessarily a place rather than an engine. Processing 
45 transfere from step 1446 to terminal step 1448 in which the processing of logic flow diagram 1414, i.e., route 
agent step 1414 (Figure 14B), completes successfully. 

Convereely, if property "means" of way 1820 (Figure 18B) is nil. way 1820 contains no means object and 
processing transfere from way has means test step 1444 (Figure 14C) to a ticket has name test step 1450. In 
ticket has name test step 1450. engine 1 32A (Figure 1 5A) produces property "destinationName" of ticket 1 306 
so (Figure 18A), which is telename 1818. and compares telenanr)e 1818 to a nil. As property "destinationName" 
of ticket 1306 is optional, property "destinationName" of ticket 1306 can be a nil (not shown). 

If property "destinationName" of ticket 1306 is a nil, processing transfers from ticket has name test step 
1 450 to ticket has provider test step 1 460. which is described below. Convereely, if property "destinationName" 
of ticket 1306 is telename 1818, processing transfere from ticket has name test step 1460 to step 1452. In step 
55 1452, engine 132A (Figure 15A) produces a way object which defines a transfer path for agent 150A to the 
transfer destination. Engine 132A consults a finder, which is described in greater detail below, to produce a 
way object to a region associated with the authority produced and copied in step 1442 (Figure 14C) above, 
and a place within that authority whose name is equal to telename 1 81 8 (Figure 18A) . The production of such 
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a way object by use of a finder is described in greater detail below. 

Processing transfers from step 1452 to a way out is here test step 1454 in which engine 132A (Figure 15A) 
determines whether the way object produced in step 1452 (Figure 14C) defines a transfer to engine 132A (Fig- 
ure 15A). If the produced way object does not define a transfer to engine 132A, processing transfers from way 
5 out is here test step 1454 to terminal step 1456 in which the processing of logic flow diagram 1414. i.e.. route 
agent step 1414 (Figure 14B), completes successfully. 

Conversely, if the produced way object defines a transfer to engine 1 32A (Figure 1 5A). processing trans- 
fers from way out is hero test step 1454 to step 1458 in which engine 132A sets a flag indicating that agent 
150A is to be transferred to engine 132A. Processing transfers from step 1458 to a second ticket has name 
10 test step 1480 which is described below in greater detail. 

As discussed above, if property "way" of ticket 1 306 is nil. processing transfers from ticket has way test 
step 1440 to ticket has provider test step 1460. In ticket has provider test step 1460, engine 132A produces 
property "destinationAddress"of ticket 1306. which is a teleaddress 1814 (Figure 18A), and produces property 
"provider" of teleaddress 1814. If either property "destinattonAddress" of ticket 1306. or property "provider" of 
15 teleaddress 1814. is a nil. processing transfers from ticket has provider test step 1460 to second ticket has 
name test step 1480. which is described below in greater detail. Conversely, if property "destinationAddress" 
of ticket 1306 (Figure 18A) and property "provider of the teleaddress 1814 are not nil. ticket 1306 specifies 
a region which contains the trip destinatton and processing transfers from ticket has provider test step 1460 
to step 1462. 

20 In step 1462, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object which defines a transfer to an engine of a region denoted by property "provider" of property "des- 
tinationAddress" of ticket 1306, Processing transfers from step 1462 (Figure 140) to afiretfound test step 1464 
in which engine 132A (Figure 15A) determines whether a way object is successfully produced in step 1462. If 
a way object is produced in step 1462. processing transfers from firet found test step 1464 to a second way 

25 out is here test step 1472, which is described in greater detail below. Conversely, if no way object is produced 
in step 1462. processing transfers from first found test step to step 1466. 

In step 1466. engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object whicMef ines a transfer to a region denoted by an item of property "routingAdvice" of the tele- 
address that is property "destinationAddress" of ticket 1306. The properties of a teleaddress, and properties 

30 "provider" and "routingAdvice" in particular, are described in greater detail in Appendix A. and that discussion 
is incorporated herein by reference. Briefly, the items of property "routingAdvice" of a teleaddress denote pro- 
viders of zero or more regions which are believed by the creator of the teleaddress to be capable of transferring 
agent ISOAto the trip destination defined by ticket 1306 (Figure 18A). Processing transfers from step 1466 
(Figure 14C) to a second found test step 1468 in which engine 132A (Figure 15A) determines whether a way 

55 object is successfully produced in step 1466. If no way object is produced in step 1466, processing transfere 
from second found test step 1468 to tenminal step 1470 in whteh an exception of dass "Destination Unavailable" 
is thrown. Conversely, if a way object is produced in step 1466. processing transfers from second found test 
step 1468 to second way out is here test step 1472. 

In second way out is here test step 1472, engine 132A (Figure 15A) determines whether the way object 

40 produced in either step 1462 or step 1466 (Figure 14C) defines a transfer to engine 132A (Figure 15A). If the 
produced way object does not define a transfer to engine 1 32A. processing transfers from second way out is 
here test step 1472 to terminal step 1474 in which the processing of logic flow diagram 1414. i.e., route agent 
step 1414 (Figure 148). completes successfully. 

Convereely. if the produced way object defines a transfer to engine 1 32A (Figure 1 5A), processing trans- 

^ fers from second way out is here test step 1 472 to step 1476 in which engine 1 32A (Figure 1 5A) derives a tel- 
ename, which identifies the destination of the trip defined by ticket 1306. from property "location" of the tel- 
eaddress that is property "destinationAddress" of ticket 1 306. 

Engine 1 32A can derive the telename in any way which is convenient and efficient For example, engine 
132A can use a table such as dictionary 2000 (Figure 20A) whose keys are octet strings, e.g., octet string 

so 2000K1. and whose values are telenames, e.g., telename 2000V1. For example* if property location" of tel- 
eaddress 1 814 (Figure 1 8A) equals octet string 2000K1 (Figure 20A). telename 2000V1 is produced by engine 
132A as the telename that specifies a place that is the destinatton of the trip defined by ticket 1306 (Figure 
18A). 

Addresses are assigned to locations within a regk)n according to an addressing scheme designed and im- 
55 plemented by the designer and implementer of the engines of the region. The disclosed instruction set does 
not prescribe a particular addressing scheme. Each regron is free to implement the most efficient and conve- 
nient addressing scheme for that particular region. Thus, as each sovereign state in the physical world designs 
and implements its own addressing scheme in providing a postal service, each region is free to implement a 
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In implementing an addressing scheme, engines of a region assign teleaddresses to locations which in- 
elude one or more places. In assigning a teleaddiBss. an engine p«)duces and stores a telename wh^S, s 
5 c,f «s one or more of the places within the location specified by the teleaddress. In other worT rlinT 

resoeSlLt'''""^^^ 

respective teleaddresses are assigned. In this way, an engine, e.g.. engine 132A(Figure 15A) can praluo^a 
10 gS^en 41 " "^^"^ "^^'sn^ «"« ""P'e"«nts the engines of a 

th«t l^^^^'^TT!"^^'^" *° ^ ^ (Figure 1 5A) sets a flag indicating 
hat agen 150A ,s to be transferred to an engine within the region which contains eng ne 132A Processino 
rans ers rom step 1478 (Figure 14C) to second ticket has name test step 1480 (Figure 14D) Rjce^olS 

teTsSM46oTth'^'^t "T ^ir:''^ 

test step 1460, both of which are described above in greater detail 

ertv'rsrafiontrJ^!' "f?r?I^n«M''° ^"^^ 132A(Figu,B 15A) determines whether prop- 

StetStirtB^rifiSffi ^ 'T " °' ""''""^ " P^P^^ -destinationNZ- 

supersedes he telename derived in step 1476 (Figure 14C) as the telename of the transfer destination. PrZ 

1 306 18 a ml. processing transfers from second ticket has name test step 1480 directly to step 1483 

«;®PJ*83, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object which defines a transfer to a place denoted by the telename produced in either step 1476 (Fioure 
14C) or Step 1482 (Figure 14D) as described above. Processing transfers'from stJ^UM to teS ste7 
7>.Hlr^!!^ TJf'^J^'* determines whether step 1458 (Figure 14C) sets the flag which indicates that 

30 4m^ l^L ^ V " processing transfers from test step 1484 (Figure 

30 14D) to a third way out is here test Step 1486. 

H, JH ^"L"^ fJ"^ ^'^P ^^S'"" ^ (Figure 15A) determines whether the way object pro- 
nl^H? f ^"^r™ '''"'"^ " ^32A (Figure 15A). If the produced way ob^t 

do«^ no def,neatrensfertoengine132A.processingtransfersfromthlrt way out is here test step 1«^^^^^ 
I^^rlnT! r i'? . '''"^^'^ '^'^^ -Destination Unavailable" is thrown and prooewing 

according to logic flow d«grem 1414 (Figures 14C and 14D). i.e.. route agent step 1414 (Figure 14B). conJ 
pletes. Com^ereeV. If the produced way object defines a transfer to a place within engine 132A (Figure 15A) 
processing transfers from test step 1486 (Figure 14D) to test step 1490 

indicates that the destination of the transfer is the region which includes engine 132A (Figure 15A) If this flag 
IS not set. pro«»ssing transfere from test step 1490 to terminal step 1496 in which processing according to logic 

S IT'Ak ^9'"' '''^ fl^'S"™ ^^B). competes sucJssfX 
Convereely if the flag is set. the transfer of agent 150A (Figure 15A) should be to a place within the region 
which include engine 132Aand processing transfere from test stop 1490 (Figure 14D) to way out is this region 
t^t^ep 1492. In way out Is this region test step 1492. engine 132A (Figure 15A) determines whether theway 
0bjert^ucedinstep1483(Figure14D)define8atran 

132A (Figure 15A). If the produced way object does not define a transfer to a place within the region which 
'"^ h!^!"^'"* ' P"~«""9 t'a"8fera from way out is this region test step 1492 (Figure 14D) to terminal 
Step 1494 in which an exception of class "Destination Unavailable* is thrown and processing according to logic 
flow diagram 1414 (Figures 14C and 14D). i.e.. route agent step 1414 (Figure 14B). completes 

As discussed above with respect to steps 1452. 1462. 1466 and 1483 (Figure 14C). engine 132A(Figure 
132A) uses a finder to route agent 150A in a transfer toward a destination of the trip defined by ticket 1306 
(Figure 1 3A). Af inder is used to determine the transfer destination for an agent For example, ticket 1 306 (Fig- 
ure 13A) defines place 220B (Figure 15A) within engine 132B as a destination of the trip. However, to reach 
engine 132B, agent ISOAmustfiret be transferred to engine 132Z. which is therefore the transfer destination 
Finder 2050 (Figure 20B) is used to produce a telename of an engine that is a transfer destination toward a 
place which IS identified by a second telename. In one embodiment, the produced telename Identifies an en- 
gine by Identifying the engine place processed by the engine. The second telename can identify a specific 
place or an authority,, thereby specifying all places of the identified authority. Telenames are described in 
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greater detail in Appendix A. 

In the context of step 1452 (Figure 14C), the second telename is telename 1818 (Figure ISA), which is 
property "destinationName* of ticket 1306. If finder 2050 (Figure 20B) contains no information regarding tele- 
name 1818, the second telename, in the context of step 1452 (Figure 14C), is a telename which identifies the 

5 authority produced and copied in step 1442 as described above. In the context of step 1462. the second tele- 
name identifies the authority specified in property "provider* of teleaddress 1814 (Figure 18A) of ticket 1306. 
In the context of step 1466 (Figure 14C)» the second telenanne identifies the authority specified in an item of 
the list that is property "routingAdvice" of telename 1814 (Figure 18A) of ticket 1306. In the context of step 
1483 (Figure 14D). the second telename is either telename 1818 (Figure 18A) of ticket 1306, if property "des- 

10 tinationName" of ticket 1306 is not nil, or the telename produced in step 1476 (Figure 14C), otherwise. Finder 
2050 (Figure 20B) is described below in the context of step 1483 (Figure 14D) in which the second telename 
is telename 1818 (Figure ISA) of ticket 1306. 

In each of steps 1452 (Figure 14C). 1462, 1466. and 1483 (Figure 14D), the telename produced by use of 
finder 2050 (Figure 20B) is used to form a way object which defines a transfer to the engine identified by the 

15 produced telename. 

Engine 132A determines to which engine to transfer agent 150A. i.e., the "transfer destination", by use of 
a finder 2050 (Figure 20B). Finder 2050 can be any data structure which allows engine 1 32A to determine, 
from a trip destinatton. a transfer destination that moves agent 150A toward the trip destination. In one em- 
bodiment, finder 2050 is a dictionary whose keys are telenames and whose values are also tetenames. The 

20 keys, e.g., telenames 2050K1-2050K6. specify authorities. The values, e.g., telenames 2050V1-2050V6, iden- 
tify engines through which places identified by each respective corresponding authority can be reached. If 
telenarrw 2050K1 (Figure 20B) of finder 2050 has the same authority as that of telename 1818. telename 
2050V1 identifies engine 132Z as the transfer destination. 

In one embodinDent of the present invention, the keys of finder 2050 include a nil 2050K7. which is asso- 

25 dated with a telename 2050V7. Telename 2050V7 kJentif ies an engine which contains information regarding 
a substantial portksn of network 1500 (Figure ISA) and networks to which network 1600 can be connected, 
either directly or indirectly. The engine which is identified by telenanne 2050V7 is therefore more likely to have 
success in routing agent 1 50A toward atrip destination which satisfies ticket 1 306 (Figure 1 8A) . If no telename 
which is a key of finder 2050 (Figure 208) is of the same authority as telename 181 8. telename 2050V7 (Figure 

30 20B). which is associated with nil 2050K7. kJentif ies the transfer destination. The following example is illus- 
trative. 

Suppose, for example, that engine 132A is executing within a smalt personal computer system and there- 
fore interprets places of only one authority. Suppose further that engine 1322 (Figure 15A) is executing within 
a large, multi-user, mainframe computer system which interprets places of many separate authorities and to 

35 which many agents of many different authorities travel. The finder of engine 1 32A would. In such a case, be 
very small and provide little informatran regarding the transportation of agents to places of particular author- 
ities. However, the finder of engine 132Z is likely to be much more extensive and comprehensive, and therefore 
much more likely to provkie informatksn regarding the routing of a particular agent to places of particular au- 
thorities. In such a case, the finder of engine 132A associates with a nil a telename which identifies engine 

40 1 32Z as the transfer destination when the finder of engine 1 32A contains no information regarding the authority 
of the trip destination place. 

If no transfer destination is successfully determined from consulting finder 2050 (Figure 20B). an engine 
can Implement any of the following or other policies according to the implementation chosen by the provider 
of the engine. If ticket 1306 (Figure 18A) contains citation 1816. engine 132A (Figure 15A) can (i) produce a 

4S telename to the current place of agent 1 50A and attempt to find a place of the cited class in the steps described 
below, (ii) throw an exception and produce no telename. thereby rejecting ticket 1306 (Figure 18A) as vague, 
or (ill) produce a telename of a place whk^h is designated as a destination of vaguely specified trips. Similarly, 
if ticket 1306 includes no citation, engine 132A (Figure 15A) can (i) throw an exception and produce no tele- 
name. thereby rejecting tteket 1306 (Figure 18A) as vague, or (ii) produce a telename of a place which is des- 

so ignated as a destination of vaguely specified trips. - 

In the example of Figures 15A-1 5E, engine 132A (Figure 15A) consults finder 2050 (Figure 20A) and de- 
termines that, to reach place 220B (Figure 15A) of engine 132B, agent 1 50Ais to be transfenred to engine 132Z. 
Therefore, the engine place of engine 132Z is the transfer d^tination of agent 150A and a way object, which 
defines a transfer of agent 150A to engine 132Z. is produced. 

55 Thus, processing according to logic flow diagram 1414 (Figures 14C and 14D) produces a way object which 

defines a transfer of agent 150A (Figure 15A) to nrwve agent 150A toward the destinatton of the trip defined 
by ticket 1306. 

As discussed above In the context of logk: flow diagram 1410 (Figure 14B). agent 150A (Figure 15A) is 
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delivered to a place In deliver agent step 1422 (Figure 14B). It is reiterated that, in the illustrative example of 
Figures 15A-15E. agent 150A is not delivered to any place within engine 132A. However, for completeness, 
the delivery of agent 150A to a place within engine 132A is discussed. Agent 150A (Figure 15A) is delivered 
to a place within engine 1 32A when that place is defined by ticket 1 306 (Figure 1 3A) as the trip destination. 

5 Delivering an agent to a place involves (i) selecting a particular place to deliver the agent (ii) making the agent 
an occupant of that place, and (iii) causing operation "go" to succeed for that agent Deliver agent step 1422 
is represented by logic flow diagram 1422 (Figure 14E), 

Processing according to logic flow diagram 1422 (Figure 14E) begins with for all cunrent places step 1422A. 
For all current places step 1422A and next step 1422C define a processing loop In which each of the places 

10 currently processed by the current engine, i.e., engine 132A (Figure 15A). Is processed accortJing to steps 
1422B. 1422D, and 1422E (Figure 14E). In the context of the following discussion of logic flow diagram 1422. 
the "subject place" is the place which is processed in a particular iteration of the loop defined by for all current 
places step 1422A and next step 1422C. For each iteration of the loop, i.e., for each cun^nt place of engine 
132A (Figure 15A), processing transfers from for all current places step 1422A to a place satisfies ticket test 

15 step 1422B. 

In place satisfies ticket test step 1422B, the current engine determines whether the subject place satisfies 
ticket 1306. 

If the subject place does not satisfy ticket 1306. either (i) processing transfers from place satisfies ticket 
test step 1422B (Figure 14E) through next step 1422C to for all cun-ent places step 1422A in which another 
20 iteration of the loop is begun, or (il) processing transfers to terminal step 14221. which Is described below. Con- 
versely, if the subject pla^ satisfies ticket 1306. processing transfers from place satisfies ticket test step 
1 422B to entering step 1422D. 

As described below in greater detail, a place grants ingress to a process, e.g. an agent by successfully 
performing operation "entering" and denies ingress to a process by throwing an exception during performance 
25 of operation "entering". Performance of operatfon "entering" is discussed in greater detail below. 

Processing transfers from entering step 1 422D (Figure 14E) to exception test step 1422E in which the cur- 
rent engine determines whether perfonmance of operatton "entering" by the subject place threw and exception. 
If performance of operatton "entering" by the subject place threw an exception, thereby denying agent 150A 
ingress to the subject place, processing transfers from entering step 1422E through next step 1422C to for all 
30 current places step 1422A in which another iteration of the loop defined by for all current place step 1422A 
and next step 1422C is begun or processing transfers to terminal step 1422J. which is described below. 

If, on the other hand, operation "entering" is performed successfully by the subject place, the subject place 
thereby granting to agent 150A (Figure 15A) ingress to the subject place, processing transfera from exception 
test step 1422E (Figure 14E) to step 1422F, In step 1422F, agent 150A (Figure 150A) is made an occupant of 
35 the subject place. Furthermore, a property of agent 150A Is set to indicate that agent 150A Is an occupant of 
the subject place. 

Processing transfers from step 1422F to step 1422G in which operation "go" as performed by agent 150A 
succeeds. As discussed above, agent 1 60A is not delivered to a place in engine 1 32A in the example of Figures 
1 5A-1 5E. Therefore, operation "go" for agent 150A does not succeed until agent 1 50A (Figure 1 5A) is delivered 

40 to place 220B in engine 132B (Figure 15E) as discussed below. Processing transfers from step 1422G (Figure 
14E) to terminal step 1422H In whteh processing according to logic flow diagram 1422. and therefore deliver 
agent step 1422 (Figure 14B), completes successfully. 

If all places which are cun-ent in engine 132A (Figure 15) are processed according to the loop defined by 
for all cunrent places step 1422A (Figure 14E) and next step 1422C and terminal step 1422H is not reached, 

46 i.e., if no place that Is current in engine 132A (Figure 15A) satisfies ticket 1306 and grants agent 150A occu- 
pancy via successful performance of operation "entering", processing transfers from for all current place step 
1422A (Figure 14E) to terminal step 14221. In terminal step 14221. an exception of class "Destination Unavail- 
able" is thrown and logic flow diagram 1422, and therefore deliver agent step 1422 (Figure 14B), completes. 
Thus, deliver agent step 1422 delivers agent 150A (Figure 15A) to a place Identified by ticket 1306 (Figure 

so 1 3A) as the destination of a trip or throws an exceptton of class "Destination Unavailable". 

As discussed above, in the example of Figures 15A-15E, engine 132Z is the transfer destination. Agent 
1 50A is therefore encoded to form encoded agent 1 50A-E (Figure 1 5B) in step 1 432 (Figure 14B) which is then 
transferred to engine 132Z (Figure 16C) in transfer out step 1434 (Figure 14B). 

55 Operation "Go* from the Perspective of an Intermediate Engine 

As described above, transfer of encoded agent 150A-E (Figure 15B) from communication infrastructure 
1 32A-CI. across communications link 1 02AZ. to communication infrastructure 1 32Z-CI (Figure 1 5C) is initiated 
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in transfer out step 1434 (Figure 14B). Appended to encoded agent 150A-E (FIgurB 21) is destination 150A- 
E-D, which includes properties "name", "address* and "data" which are telename 2102, teleaddress 2104 and 
octet string 2106. respectively. Telename 2102 and teleaddress 2104 define the transfer destination of encod- 
ed agent 1 50A-E. The transfer destination as defined by destination 1 50A-E-D (Figure 21 ) can t)e either engine 
5 1 322 (Figure 1 5B) or engine 1 32B, In one embodiment of the present invention, destination 1 50A-E-D (Figure 
21), which is fonmed in form destination step 1430 (Figure 148). defines engine 1 32Z (Figure 1 5B) as the trans- 
fer destination of encoded agent 150A-E. In that case, communications infrastructure 132A-CI transfers en- 
coded agent 150A-E directly to communications infrastructure 132Z-CI of engine 132Z. In another embodi- 
ment of the present invention, destination 1 50A-E-D (Figure 21 ) defines engine 1 32B (Figure 1 5B) as the trans- 
10 fer destination of encoded agent 150A-E. In the latter case, communications infrastructure 132A-CI contains 
information and logic which causes communications infrastructure 132A-Ct to transfer encoded agent 150A- 
E. which is destined for engine 132B according to destination 150A-E-D (Figure 21). to communications infra- 
structure 1 32Z-CI (Figure 15B) or engine 1322L 

In either embodiment described above, when engine 1322 (Figure 15C) receives encoded agent 150A-E, 
15 engine 1322 performs a system operation detemiined rn route agent step 1414 "transferin" which is shown as 
logic flow diagram 1400-1 (Figure 14F). Engine 1322 (Figure 15C) begins perfomiance of system operation 
"transferin" by producing a way object which defines a transfer to destination 150A-E-D (Figure 21) in step 
1402-1 (Figure 14F). Engine 1322 produces a way object in step 1402-1 (Figure 14F) by consulting a finder 
within engine 1 322 (Figure 15C) as described above with respect to finder 2050 (Figure 208). 
20 Processing transfers from step 1402-1 (Figure 14F) to a fourth way out is here test step 1404-1 in which 
engine 1322 (Figure 15C) determines whether the way object produced in step 1402-1 (Figure 14F) defines a 
- transfer to engine 1322 (Figure 15C). If the produced way object does not specify engine 1322 (Figure 15C) 
as the transfer destination, i.e.. if destination 150A-E-D (Figure 21) defines engine 1328 (Figure 15B) as the 
transfer destination, processing transfers from fourth way out is here test step 1404-1 (Figure 1 4Fs) to a second 
25 transfer out step 1406-1. In second transfer out step 1408-1, engine 1322 (Figure 15C) initiates transfer of en- 
coded agent 150A-E according to destination 150A-E-D (Figure 21) in a manner directly analogous to that de- 
scribed above with respect to transfer outstep 1434 (Figure 148). 

Processing transfers from second transfer out step 1406-1 to step 1408-1. In step 1408-1, engine 1 322 (Fig- 
ure 15C) adds encoded agent 150A-E to a list of pending transfers as described above with respect to step 
30 1438 (Figure 14B). Processing transfers from step 1408-1 (Figure 14F) to terminal step 1410-1 in which system 
operation "transferin" completes successfully. 

Thus, if the way object produced in step 1402-1 defines a transfer to engine 1328 (Figure 15C), encoded 
agent 150A-E is transfen-ed according to the produced way object If. on the other hand, the produced way 
object defines a transfer to engine 1 322. processing transfers from fourth way out Is here test step 1 404-1 (Fig- 
35 ure 14F) to step 1412-1. In step 1412-1, engine 1322 (Figure 15C) extracts from encoded agent 150A-E ticket 
1306 (Figures 13A and 18A) and forms a copy of ticket 1306. Processing transfers from step 1412-1 to step 
1414-1 in which property "way" of the ticket copy is cleared, i.e., set to a nil. Processing transfere from step 
1414-1 to a second route agent step 1416-1 in which engine 1322 produces a way object defining a transfer of 
encoded agent 150A-E. The process pertbmied in step 1416-1 is identical to the process represented by logic 
^ flow diagram 1414 (Figures 14C and 14D). In the context of second route agent step 1416-1, ticket 1 306 used 
in the above discussion of logic flow diagram 1414 is replaced by the ticket copy made in step 1412-1. and the 
logk: flow diagram is processed as described above using the ticket copy. Upon completion of step 1416-1. 
processing transfers to a fifth way out is here test step 1418-1. 

In fifth way out is here test step 1418-1. engine 1322 (Figure 15C) detemnines whether the way object pro- 
46 duced in step 1416-1 (Figure 14F) defines a transfer to engine 1322 (Figure 15C). If the produced way object 
defines a transfer to engine 1 322. processing transfers from fifth way out is here test step 141 8-1 (Figure 1 4F) 
to a decode agent step 1 428- 1 which is described below in greater detail. Conversely, if the produced way object 
does not define a transfer to engine 1322 (Figure 15C), processing transfere from fifth way out is here test 
step 1418-1 (Figure 14F) to a second form destination step 1420-1. In the example of Figures 15A-15F, ticket 
so 1 306 (Figure 13A). which is extracted from encoded agent 150A-£ and copied, defines a trip to place 2208 
of engine 1328 (Figure 15C). Therefore, processing transfers to second form destination step 1420-t. 

In fbnm destination step 1420-1, engine 1322 (Figure 15C) fonms. i.e., supereedes, destination 150A-E-D 
(Figure 21) in a manner that is directly analogous to that described above with respect to form destination step 
1430 (Figure 14B). Processing transfere from second fomi destination step 1420-1 (Figure 14F) to a third trans- 
55 fer out step 1422-1. In third transfer out step 1422-1. encoded agent 1 50A-E (Figure 1 5C) is transferred accord- 
ing to destination 150A-E-D (Figure 21) as described above with respect to second transfer out step 1406-1 
(Figure 14F). 

Processing transfere from third transfer out step 1422-1 to step 1424-1. In step 1424-1. engine 1322 (Figure 
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1 5C) adds encoded agent 150A-E to a list of pending transfers as described above with respect to step 1438 
(Figure 14B). Processing transfers from step 1424-1 (Figure 14F) to terminal step 1426-1 in wtiich system op- 
eration "transferin" completes successfully. In the example of Figures 15A-15R encoded agent 150A-E is 
transferred from engine 132Z to engine 132B (Figure 15D) in a manner that is directly analogous to the transfer 
5 of encoded agent 1 50A-E from engine 1 32A to engine 1 32Z as described above. 

Operation "Go" from the Perspective of the Destination Engine 

When engine 132B receives encoded agent 150A-E in communication infrastructure 132A-CI (Figure 

10 15D), engine 132B performs system operation "transferin" In a manner similar to that described above with 
respect to engine 1 322. Engine 1 32B produces a way object defining a transfer according to destination 1 50A- 
E-D (Figure 21) in step 1402-1 (Figure 14F) and determines whether the produced way object defines a transfer 
to engine 1 32B (Figure 1 5D) in fourth way out is here test step 1404-1 (Figure 14F). Since engine 132B (Figure 
15D) processes place 220B which is the destination of the trip defined by ticket 1306 (Figure 13A). the pro- 

15 duced way object defines a transfer to engine 132B (Figure 15D). Therefore, processing by engine 132B trans- 
fers from fourth way out is here test step 1404-1 (Figure 14F) to step 1412-1. 

In steps 1412-1. 1414-1 and 1416-1. engine 132B extracts and copies ticket 1306 (Figure 13A) from encoded 
agent 150A-E. clears property "way" of the ticket copy, and routes encoded agent 150A-E according to logic 
flow diagram 1414 (Figures 14C and 14D) except now the ticket copy is used for ticket 1306 in the above de- 

20 scriptton. In fifth way out is here test step 1418-1 (Figure 14F). engine 132B (Figure 15D) determines whether 
the way object produced in second route agent step 1416-1 (Figure 14F) defines a transfer to engine 132B (Fig- 
ure 15D), Since engine 132B (Figure 15D) processes place 220B. the produced way object defines a transfer 
to engine 132B (Figure 15D). Therefore, processing by engine 132B transfers from fifth way out is here test 
step 1418-1 (Figure 14F) to decode agent step 1428-1. 

25 In decode agent step 1428-1, engine 132B decodes agent ISOAfrom encoded agent 150A-E (Figure 15D) 

in communication infrastructure 132B-CI by reverse application of the encoding rules described in Appendix 
B and stores agent 150A in data portion 132B-D (Figure 15E). As network 1500 can be heterogeneous, the 
form of agent 1 50A within engine 1 32A (Figure 1 5A) may be inconvenient for representing agent 1 50A within 
engine 1 32B (Figure 15E). As long as the standardized form of encoded agent 1 50A-E is used to transfer agent 

30 1 50A between engines 1 32A and 1 32B. engine 1 32B can represent agent 1 50A in whatever form is niost con- 
venient for engine 132B when not transferring agent 150A. 

Processing by engine 132B transfers from decode agent step 1428-1 (Figure 14F) to deliver agent step 
1430-1. In deliver agent step 1430-1. agent 150Ais delivered according to logic flow diagram 1422 (Figure 14E) 
as described above with respect to deliver agent step 1422 (Figure 14B). In the context of deliver agent step 

35 1430-1, the ticket is now the actual ticket 1306 (Figure 13A) and not the postulated ticket In deliver agent step 
1430-1 (Figure 14F). agent 150A (Figure 15E) is granted occupancy in place 220B and operation "go" as per- 
fonmed by agent 150A completes successfully. 

Processing transfers from deliver agent step 1430-1 (Figure 14F) to terminal step 1426-1 in which process- 
ing according to logic flow diagram 1400-1 (Figure 14F). i.e., performance of system operation "transferin", by 

40 engine 132B completes successfully. 

Any exception thrown in the course of performing the steps of logic flow diagram 1400-1 (Figure 14F) caus- 
es performance of the steps of logic flow diagram 1450-1 (Figure 14G). Agent 150A is decoded from encoded 
agent 150A-E (Figure 15D) in step 1452-1 (Figure 14F). Since agent 150A arrived in engine 132B (Figure 15D), 
agent 1 50A is not retained in a list of pending transfers as described above with respect to engine 1 32A. There- 

45 fore, it is necessary to decode agent 150A to continue execution of agent 150A. Processing transfera from 
step 1452-1 (Figure 14G) to deliver agent step 1454-1 in which agent ISOAis delivered to purgatory as described 
above with respect to step 1426 (Figure 14B). Processing transfere from deliver agent step 1454-1 (Figure 14G) 
to terminal step 1456-1 in which processing according to logic flow diagram 1450-1 completes. Agent 150A. 
which occupies purgatory as a resultof deliver agent step 1454-1. throws the exception which caused perfor- 

50 mance of logic flow diagram 1450-1, thereby causing operation "go" as performed by agent 1 50A to fail. 

Thus, agent 150A (Figures 15A-15E), by performance of operation "go", directs nrravement, i.e., transpor- 
tation, of agent 150A. and objects owned by agent ISOAsuch as objects 140Aand 140B. through network 
1500. After performance of operation "go", interpretation of agent 150A continues with the instruction within 
agent 150A which immediately follows operation "go*. 

55 Figure 1 3B shows a portion of the execution state and of the internal state of agent 150 A immediately fol- 

lowing performance of operation "go" by agent 1 50A. At the top of stack 1 304 is ticket stub 1 308 which is the 
result produced by performance of operation "go". Place 220B is the property of agent 150A identifying the 
place occupied by agent 150A. thereby indicating that agent 150A occupies place 220B. 
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Ingress and Egress: Operations "Entering" and "Exiting" 

As discussed alx)ve, place 220B grants or denies ingress to agent 1 50A by perfonmance of operation "en- 
tering". The embodiment disclosed above with respect to logic flow diagram 1400 (Figures UAand 14B) trans- 
5 ports encoded agent 150A-E (Figures 15A-15E) to engine 132B before requesting that place 220B perform 
operation "entering". In another embodiment of the present invention, place 220B is directed to perform oper- 
ation "entering" before agent 150A is transported across communications link 102A2. through communication 
infrastructure 1322-CI, across communications link 1022B to engine 132B. By performing operation "enter- 
ing", place 220B either grants or denies agent ISOApermisston to occupy place 2208. However, it is anticipated 
10 that the present invention will be used in wide-area networks with high latency. 

The term "latency" is used herein as it is used in the art to denote the amount of time between the time 
Information is first sent by the sender of the information and the time information is first received by the receiver 
of the informatton. In networks with high latency, even short messages can require substantial an)ounts of time 
to reach a destination. In such a case, requesting that place 220B (Figure 15A) perform operation "entering" 
15 and awaiting a result involves sending a request across communications link 102A2, through communication 
infrastructure 132Z-CI, across commun nations link 1 02ZB and through engine 132B to place 220B to perform 
operation "entering" and awaiting receipt of the result produced by operation "entering" by the reverse path. 
Doing so before transporting agent 1 50A to engine 1 32B postpones the transportation of agent 1 50A to engine 
1 32B by an amount of time approximately equal to twice the latency between engines 1 32A and 1 328. There- 
to fore, to substantially improve the performance of the present invention, perfomnance of operatton "entering" 
by place 220B is postponed until agent 150A Is transported to engine 132B. 

While op4>ratk)n "entering" is described in the context of agent 150A (Figure 15E) entering place 220B as 
a consequence of operation "go", operation "entering" is also performed as a consequence of a process, either 
an agent or a place, entering place 220B as a consequence of the process's creation within place 220B. The 
25 creation of a process is discussed in greater detail in Appendb( A. 

Figure 22A gives the execution state of agent 1 50A immediately prior to performance of operation "enter- 
ing". The execution state of a process, e.g., agent 150A, is described in greater detail below. Operation "en- 
tering" is performed at the request of engine 132B. and the perfonmance of "entering" is recorded in the exe- 
cution state of agent 1 50A (Figure 1 5E). The permit of either agent 150Aor place 2208, preferably place 2208, 
30 may be debited by performance of operation "entering". 

Frame 2200 is part of the execution state of agent 150A and records the dynamic state of operation "en- 
tering" as perfomried by place 2208. Frame 2200 includes stack 2202 which is the current stack. Stack 2202 
contains, from top to bottom, contact 2208, permit 2206 and ticket 2204. 

Contact 2208 Identifies agent 150A as the process attempting to enter place 2208. As discussed below 
35 in greater detail and In Appendix A, a contact has, among Its properties, a property "subjectName" and a prop- 
erty "subjecr. Property "subjecT of contact 2208, whfch Is ordinarily a reference to agent 150A, is nil in oper- 
atton "entering" so that place 220B is not given a reference to agent 150A before place 220B grants ingress 
to agent 150A. Property "subjectName" of contact 2208 is a telename which identifies agent 1 50Aas the agent 
requesting ingress to place 220B. 
40 Permit 2206 ts the proposed local permit of the agent attempting to "enter" place 2208. Permit 2206 is 
passed "byProtectedReT and therefore cannot be altered by performance of operation "entering". The passing 
of arguments and results, and in particular passing by protected reference, i.e., "byProtectedRef", is described 
below in greater detail. An agenf s local permit defines the capabilities of the agent while at a given place. For 
example, agent 150A can limit itself to a subset of the capabilities and allowances of its native permit while at 
45 place 2208 by supplying to place 2208 permit 2206 which defines the subset of capabilities and allowances. 
Ticket 2204 is passed "byProtectedRer and is eq ual to ticket 1 306 used to travel to responding place 2208 
and informs responding place 2208 that agent 150A is attempting to enter from another place. If ticket 2204 
is a nil, a process is attempting to enter responding place 2208 by the process's creation within responding 
place 220B. 

so The method by which a place detenmines whether to admit a process, Le., the method implementing op- 
eratton "entering", as defined by class "Place" always throws an exception that is a member of dass "Occu- 
pancy Denied", thereby denying the process ingress to the responding place. However, users of the present 
invention define subclasses of class "Place" which grant entrance to processes under specific circumstances. 
Such is a practical necessity for agents to travel from one place to another. 

55 As the implementation of operation "entering", as performed by a place, is defined by the particular method 

provided by or inherited by the dass of which the place is an instance, each place can implement operation 
"entering" differently from other places in the network. Logic flow diagram 2260 (Figure 22C) serves as an 
illustrative example of an implementatton of operatton "entering" and therefore of the steps taken by place 2208 
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in performance of operation "entering' in entering step 1448 (Figure 14B). 

Contact 2208. permit 2206 and ticket 2204 are popped from stack 2202 in steps 2262. 2264 and 2266, 
respectively (Figure 22C). Processing then transfers to ticket test step 2272 in which ticket 2204 is compared 
to a nil. If ticket 2204 is a nil, agent 150A is being created locally and processing transfers to terminal step 
5 2274 where operation "entering" completes successfully. However, it is apparent in view of the foregoing and 
the following that a place can be defined such that operation "entering" fails under certain circumstances so 
as t0 prevent the creation of a process within the place. 

If ticket 2204 is not nil. processing transfers from ticket test step 2272 to allowance test step 2276. In al- 
lowance test step 2276. property "charges" of permit 2206 is produced by querying attribute "charges" of pemilt 
10 2206 and property "charges" of permit 2206 is compared to 1 000. If property "charges" of pernnit 2206 is greater 
than 1000. processing transfers from allowance test step 2276 to terminal step 2278 where an exception of 
class "Occupancy Denied" is thrown, denying the agent ingress into the responding place. If property "charges" 
of permit 2206 is less than or equal to 1000. processing transfers from allowance test step 2276 to terminal 
step 2274 where operation "entering" terminates successfully, granting the agent ingress into the responding 
15 place. The exact number 1000 as a maximum pemiissible charges allowance in the example of Figure 22C is 
chosen arbitrarily for purposes of illustratk^n. 

The method of logic flow diagram 2260 is illustrative of an appropriate implementation of operation "en- 
tering" for places processed by an engine operating within a personal computer systenri with limited resources. 
As discussed above and in Appendbc A. property "charges" of a permit is an allowance of processing. Thus, 
20 according to logic flow diagram 2260. agents, which indicate by a large charges allowance in their proposed 
local permits a need for large amounts of computation and resources, are denied ingress. Thus, the owner of 
a small personal computer system can restrict her personal computer system to processes created locally and 
to relatively inexpensive visits by agents created elsewhere. 

Immediately following performance of operation "entering" by place 2208 (Figure 22B), stack 2202 is emp- 
25 ty as operation "entering" produces no result 

As discussed above, a place notes the departure, i.e.. the termination of occupancy, of a process by per- 
formance of operation "exiting". In the context of logic flow diagram 1400 (Figures 14A and 14B). place 220A 
is performing operation "exiting" as a result of an agent, i.e.. agent 1 50A, leaving place 220A as a consequence 
of operation "go". Operation "exiting" is also performed by place 220A when a process, either an agent or a 
30 place, no longer occupies place 220A as a consequence of the process's destruction. The destruction of a 
process is described in greater detail in Appendix A, The interface of operation "exiting" as defined by dass 
"Place" is shown by Figures 23A and 23B. 

As operation "exiting" is performed at the request of engine 1 32A (Figure 1 5A), frame 2300 (Figure 23A). 
which records the dynamk: state of operation "exiting". Is neither part of the execution state of place 220A(Fig- 
35 urs 1 5A) nor part of the executton state of agent 1 50A. In fact, at the time at which place 220A is performing 
operation "exiting", agent 150A no longer occupies place 220A. Engine 132A creates a new execution state 
as part of an "engine process". An engine process is a process created by an engine for the purpose of carrying 
out a performance of operation "exiting" or of operatton "parting". Operation "parting" is discussed below and 
in Appendbc A. 

« Figure 23A illustrates frame 2300 immediately prior to perfbnmance of operation "exiting". Frame 2300 in- 

cludes stack 2302. which is the current stack. Stack 2302 contains as the arguments of operation "exiting", 
from top to bottom, contact 2308, permit 2306 and tteket 2304. 

Contact 2306 identifies agent 150A (Figure 15A) as the process exiting place 220A. As discussed below 
in greater detail and in Appendbc A, a contact has, among its properties, a property "subjectName" and a prop- 
4S erty "subjecT. Property "subjectName" of contact 2308 (Figure 23A) identifies agent 150A (Figure 15A); prop- 
erty "subject" of contact 2308 (Figure 23A). which is ordinarily a reference to agent 1 50A (Figure 1 5A), is voided 
in operation "exiting" so that place 220A is not left with a reference to exiting agent 1 50A. 

Permit 2306 (Figure 23A) is the current local permit of the process exiting responding place 220A (Figure 
1 5A), l.e. of agent 150A. A process's local permit defines the capabilities of the process while occupying a given 
so place. Local penmits are discussed in greater detail in Appendix A. Permit 2306 (Figure 23A) is passed "by- 
ProtectedRef" and therefore cannot be altered by place 220A (Figure 15A) in performing operation "exiting". 
The local penmit of the exiting process. i.e.. permit 2306 (Figure 23A), is used by the engine interpreting 
responding place 220A (Figure 15A) to determine the type and amount of resources used by the exiting process 
during occupancy of place 220Aso that the authority of the exiting process can be billed for use made of place 
55 220A and resources contained therein. The type and amount of resources used are determined by comparison 
between permit 2306 (Figure 23A) and the permit consumed as an argument In operation "entering" when 
granting ingress to the exiting process. Operation "entering" is discussed in greater detail above and in Ap- 
pendbc A. 
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For example, place 220A (Figure 1 5A) In performing operation "entering", can store the proposed local per- 
mit e.g., permit 2206 (Figure 22A), for later comparison with permit 2306 (Figure 23A), which is consumed in 
performance of operation "exiting". As described below and in Appendix A. a contact, e.g.. contact 2308, has 
a property "subjectNotes". In one embodiment, place 220A stores, within property "subjectNotes" of contact 

5 2208 (Figure 22A), permit 2206 in perfonming operation "entering". In perfonming operation "exiting", place 
220A (Figure 1 6A) detennines the amount of resources consumed by agent 1 50A while occupying place 220A 
by comparing permit 2206 (Figure 22A). which is stored within property "subjectNotes" of contact 2208. with 
permit 2308 (Figure 23A). which is consumed in performance of operation "exiting". 

Ticket 2304 (Figure 23A) is passed "byProtectedRer and is equal to ticket 1 306 (Figure 1 3A) which is used 

10 by agent 150A (Figure 15A) to specify the destination of the trip and informs responding place 220Athat agent 
1 50A is leaving responding place 220A as a consequence of perfonming operation "go". If ticket 2304 (Figure 
23A) is a nil. agent 150A (Figure 15A) is exiting responding place 220A as a consequence of the destruction 
of agent 150A. 

Frame 2300 (Figure 23B) is shown immediately following perfomiance of operation "exiting" by place 220A 
15 (Figure 1 5A) . Stack 2302 (Figure 23A) is empty as operatton "exiting" produces no result As frame 2300 (Fig- 
ure 23B) is not part of the executran state of either place 220A (Figure 1 5A) or agent 1 50A, but is instead part 
of the execution state of an engine process, any exception thrown by performance of operation "exiting" is not 
experienced by, and therefore has no effect upon, either place 220A or agent 150A. In performing operation 
"exiting", place 220A notes the departure of agent 150 A and objects 140A and i40B. which are owned by agent 
20 150A. 

Object Interchange 

The time required to transport an agent from one place to another is substantially reduced by limiting trans- 

25 portation of objects contained by the agent to only those objects that are not likely to have an equivalent object 
at the destination place. Limiting transportation of such objects is particularly important as agent 1 50A, in trav- 
eling from engine 132Ato engine 132Z. includes class objects representing the classes of which agent 150A 
and objects owned by agent 150A are members. As class objects are typically quite large and as the classes 
of which an agent and the objects owned by the agent are members are typically quite numerous, transporting 

30 all such class objects is impractical. Thus, it is prefen-ed that in transporting agent 1 50A from engine 1 32A to 
engine 1 32B (Figure 1 5A), only dass objects representing classes, which are not represented by dass objects 
in engine 132B. are transported with agent 150Ato engine 1328. 

Objects, that are likely to have equivalent objects at most places within network 1500 (Figures 15A-16E), 
are members of mix-in dass "Interchanged" and therefore Include a property "digesr. Members of mix-in dass 

35 "Interchanged" are called "Interchanged objects". The object which is property "digesr of an Interchanged ob- 
ject is alternatively called "the digest" of the interchanged object 

An interchanged object is one that an engine, e.g. engine 132Aor 132B (Figure 15A). deems equivalent 
to any other instance of the interchanged object's dass whose digest is equal to the digest of the interchanged 
object. A digest is any object suited to the purpose of distinguishing a first interchanged object from all others. 

40 For example, a mathematical hash of a canonical binary representation of the interchanged object is suitable 
for many classes of interchanged objects. Class objects, i.e., objects of dass "Class", define built-in dasses 
as well as user-defined dasses. as described more completely below and in Appendix A, and do not vary from 
engine to engine within computer network 1500. Class objects are therefore Interchanged objects. 

The use of digests to reduce the amount of data transferred, and therefore to reduce the time required to 

45 transport an agent and the objects contained by that agent from one place to another, is illustrated by logic 
flow diagrams 2400 and 2450 (Figures 24A and 24B). 

Logic flow diagram 2400 (Figure 24A) represents the process of transporting agent 150A (Figure 15A) and 
the objects contained by agent 150Afrom a source engine 132Ato a destinatton engine 132B when inter- 
changed objects are considered. An agent "contains" all objects owned by the agent as well as every dass of 

so which the agent is a member and every dass of which any object owned by the agent is a member. As described 
above, agent 150A and all objects contained by agent 150A are packaged into a shipping box. encoded and 
transported to engine 132B. In packaging agent 150A and objects contained therein, source engine 132A col- 
lects all objects contained by agent 150A in step 2402 (Figure 24A). Processing transfers from step 2402 to 
for each object step 2404 which, with next step 1412. defines a loop wherein each object collected in step 2402 
55 is considered. Processing transfers from for each object step 2404 to digest test step 2406 in which the dass 
membership of each object contained by agent 1 50A is checked to determine whether each object has a digest 
As discussed above and in greater detail in Appendices A and E. membere of mix-in dass "Interchanged" 
can include a digest Therefore, if an object has a digest the object is an interchanged object If an interchanged 
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object does not have a digest, i.e.. if attribute "digest" of the interchanged object is a nil. the interchanged object 
Is not interchanged but is instead treated as a non-interchanged object 

If an object has no digest, even if the object is an interchanged object, processing transfers from digest 
test step 2406 to step 2410 in which the object is encoded according to the encoding rules of Appendix B and 
5 included in the shipping box. Otherwise, if the object has a digest, processing transfers from digest test step 
2406 to step 2408 in which the digest of the object and a citation of the class of which the object is an instance 
are encoded according to the encoding rules of Appendbc B and included in a parts box which is in turn included 
in the shipping box. 

Processing transfers from step 2408 or step 241 0 to next step 2412 in which processing is transferred to 
10 for each object step 2404. Engine 1 32A repeats the process of steps 2406, 2408 and 241 0 for each object con- 
tained by agent 150A in a loop defined by for each object step 2404 and next 2412. If all objects collected in 
step 2402 have been processed according to the loop of for each object step 2404 and next object step 2412, 
processing transfers from for each object step 2404 to a transfer out encoded agent step 2414. 

In transfer out encoded agent step 2414. the shipping box is encoded and is transported by source engine 
15 132AtD destination engine 132B. as described above. Thus, the encoded agent which is transported to des- 
tination engine 1328 includes all objects contained by the agent which have no digests and the digests of all 
objects contained by the agent which are interchangeable and which have digests. Transfer out encode agent 
step 2414 is represented in double boxes to indicate interaction between engines across the network. Such 
an exchange of binary data between engines is discussed above and in Appendices C and F. 
20 Logic flow diagram 2450 (Figure 248), illustrates the transfer of encoded agent 150A from the perspective 

of destination engine 132B. Destination engine 132B receives the encoiJed agent as binary data from source 
engine 132A in transfer in encoded agent step 2462. As described above in the context of Figures 15A-15E. 
the encoded agent can pass through one or more intermediate engines, e.g.. engine 132Z. enroute f rom engine 
132Ato engine 1328. 

25 Processing transfers from transfer In encoded agent step 2452 to step 2454 in which the encoded agent 

is decoded, thereby reconstructing the shipping box whose contents are the agent objects contained by the 
agent. Each of the objects, which do not have digests and which are contained by the agent, and the digests 
of the interchanged objects contained by the agent which have digests, are processed by destination engine 
1 32B according to the loop fomied by for each object step 2456 and next step 2462. Each iteration of the loop 

30 processes one of the objects decoded in step 2454. 

Processing transfers from for each object step 2454 to digest test step 2464. In digest test step 2464, des- 
tination engine 1 328 determines whether an object is a digest If the object is notadlgest processing transfers 
from digest test step 2464 directly to next object step 2462. Conversely, if the object is a digest processing 
transfers from digest test step 2464 to test step 2466 and the object is called "the subject digesr. In test step 

35 2466. destination engine 1328 determines whether the subject digest is equivalent to a digest of an inter- 
changed object which is present in engine 1328. The method by which such a determination is made is dis- 
cussed in more detail below. 

If an interchanged object having an equivalent digest Is found in step 2466, processing transfers from test 
step 2466 to substitute step 2468. In substitute step 2468, the interchanged object is substituted for the subject 

40 digest by replacing all references within the objects decoded in step 2454 to the Interchanged object repre- 
sented by the subject digest with references to the found interchanged object. Processing transfere from sub- 
stitute step 2468 to next object step 2462. 

If, on the other hand, no interchanged object having an equivalent digest is found in test step 2466. proc- 
essing transfers from test step 2466 to step 2470. In step 2470, the subject digest is added to a list of digests. 

« A new list is created if no such list exists. Processing transfers from step 2470 to next step 2462. 

From next step 2462, processing transfers to for each object step 2456. If all objects decoded in step 2454 
have been processed according to the loop of for each object step 2456 and next step 2462, processing trans- 
fers from for each object step 2456 to a list test step 2476. which is described below. 

An engine searches for equivalent interchangeable objects In step 2466 as follows. Each engine contains 

50 one or more places which can exchange equivalent interchangeable objects. Each such place includes a "re- 
pository" of interchangeable objects which are present within the place. Dictionary 2490 (Figure 24D) is the 
repository of place 2208 (Figure 15D). The keys of dictionary 2490 (Figure 24D) are classes, i.e.. classes 
2490K1. 2490K2. 2490K3 and 2490K4. Associated with each class is a dictionary; for example, associated 
with classes 2490K1-2490K4 are dictionaries 2490A. 24908, 2490C and 2490D. respectively. 

'*s Each of dictionaries 2490A-2490D have the same general organization; dictionary 2490A is illustrative. 

The keys of dictionary 2490Aare digests, i.e., digests 2490AK1 . 2490AK2 and 2490AK3. Associated with each 
digest is an interchanged object whose digest is the associated digest; for example, associated with digests 
2490AK1-2490AK3 are interchanged objects 2490AV1. 2490AV2 and 2490AV3. respectively. 
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An interchanged object is retrieved from dictionary 2490 in two steps. As discussed atwve, both a digest 
and a citation of a class are used within a parts box to represent an interchanged object In the first step, a 
citation is used to retrieve the dictionary of dictionaries 2490A.2490D which is associated with the dass ref- 
erenced by the citation. For example, if the citation references class 2490K1 , dictionary 2490A is retrieved. 

5 In the second step, the retrieved dictionary Is searched for an association between a digest equivalent to 

the digest which Is Included in the parts box and an interchanged object an association is found, the inter- 
changed object is retrieved. If no association is found, the place contains no interchanged object which is equiv- 
alent to the interchanged object represented by the citation and digest in the parts box. Thus, a repository such 
as dictionary 2490 (Figure 24D) Is used to determine whether a place contains an equivalent interchanged ob- 

10 ject and to retrieve such an object 

As described above, processing transfers from for each object step 2456 to list test step 2476. In list test 
step 2476, the destination engine, e.g. engine 1 32B. determines whether a list of digests was created In step 
2470 and, if so, whether the list is empty. If the list of digests does not exist or Is empty, processing transfers 
from list test step 2476 to activate traveling agent step 2478 in which engine 132B activates traveling agent 

15 1 50A by scheduling agent 1 50A for execution. Processing transfers from activate traveling agent step 2478 
to terminal step 2479 in which the transfer of agent 150A. as earned out by engine 132B, completes success- 
fully. 

If. on the other hand, a list was created In step 2470 and the list contains at least one digest, an equivalent 
object for at least one Interchanged object Is not found within destination engine 1 328 and processing transfers 

20 from list test step 2476 to hold traveling agent step 2471. In hold traveling agent step 2471, traveling agent 
1 50A Is held In a suspended state in a holding queue within engine 132B. Processing transfers from hold trav- 
eling agent step 2471 to step 2472. 

In step 2472. the destination engine, e.g. engine 132B, creates an object retrieval agent, i.e., an "ORA". 
The ORA retrieves interchanged objects from the source engine, e.g., engine 132A according to logic flow di- 

25 agram 2480 (Figure 24C). Processing transfers from step 2472 to step 2474 in which the ORA is directed to 
perform operation live", thereby Initiating Interpretation of the ORA. As discussed below in greater detail, the 
central activity of the ORA Is shown by logic flow diagram 2480 (Figure 24C). Processing transfers from step 
2474 to terminal step 2479 in which the transfer of agent 150A. as carried out by engine 132B, completes suc- 
cessfully. It should be noted that traveling agent 150A is not activated and is in the form of a shipping box. 

30 Agent 150A is reconstituted from the shipping box and reactivated by the ORA as described below. 

Logic flow diagram 2480 (Figure 240) Illustrates the central procedure of the ORA. In step 2482, the ORA 
travels to the source engine, e.g., engine 132A. by performance of operation "go". Processing transfers from 
2482 to step 2484 in which the ORA collects from an interchanged object repository, such as dictionary 2490 
(Figure 24D), within engine 1 32A a copy of each object having a digest that Is equivalent to a digest contained 

35 in the list of digests. Processing transfers from step 2484 to step 2485. 

In step 2485, the ORA travels back to the destination engine, e.g.. engine 1 32B. by performance of oper- 
ation "go". The ORA carries to the destination engine copies of those objects whose digests are contained in 
the list of digests, namely, those objects for which there are no equivalent objects within the destination engine. 
Processing transfere from step 2485 to step 2486. In step 2486, the ORA substitutes the objects collected for 

40 the digests within agent 150A as described above. Processing transfers from step 2486 to activate traveling 
agent step 2487. in which agent 1 50A is reconstituted from the shipping box and activated as described above. 
The reconstitutlon of an agent and the objects contained by the agent from a shipping box is described in great- 
er detail in Appendix D. Processing transfere from step 2487 to terminal step 2488 in which the central proce- 
dure of the ORA is successfully completed. 

46 Thus, efficiency is achieved by transporting across network communications media only those Inter- 

changed objects which are not equivalent to interchanged objects within the destination engine. 

Operation "Send" 

50 An agent is capable of traveling to several places simultaneously by performing operation "send". Figure 
25 shows the state of network 2500 prior to perfonmance of operatwn "send" by agent 150A. In the example 
of Figure 26. agent 150A In data portion 132A-D of engine 132A is configured to transport a done of itself to 
place 220B In data portion 132B-D of engine 132B and a done of Itself to place 2200 In data portion 1320-D 
of engine 1320 simultaneously. In other words, agent 150A Is performing operation "send", supplying as the 

55 argument to operation "send" a list of two tickets specifying places 220B and 2200 as destination places for 
clones of agent 1 50A. A done of agent 150A is a copy of agent 1 50A which is made by replicating agent 1 50A, 
including the execution state of agent 150A. to form the copy and which is made "active" by assigning a new 
name and identifier to the copy and scheduling the copy for execution by an engine. Clones are described in 
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greater detail in Appendix A. 

The interface of operation "send" is illustrated by Figures 26A, 26B and 26C. Figure 26A illustrates frame 
2602, which records the dynamic state of operation "send" as performed by agent 150Aand which is a part of 
the execution state of agent 150A. immediately prior to performance of operation "send". The execution state 
5 of a process, including an agent is described in greater detail below and in Appendices A and B. 

Included in frame 2602 is stack 2604. Stack 2604 is the stack from which arguments are popped and to 
which a result is pushed during perfbnmance of operation "send". Stack 2604 is therefore the "current stack" 
In the context of operation "send". The "current stack" is defined and explained more completely below and In 
Appendices A and B. 

10 At the top of stack 2604, as indteated by letter "T, is list 2606 whose items are tickets 2608 and 2610. 
Tickets 2608 and 2610 of list 2606 each define a trip to be taken by a con-esponding done of agent 150A. 

Objects 2618 and 2620 are property "travelNotes" of tickets 2608 and 2610, respectively. Objects 2618 
and 2620 provide a mechanism by which respective clones created by performance of operation "send" can 
be distinguished. For example, in forming tickets 2608 and 2610, agent 150Acan store within objects 2618 

15 and 2620 strings whose respective texts are "Able" and "Baker". In such a case, the clone of agent 1 50A cor- 
responding to ticket 2608 retrieves the string "Able" from property "travelNotes" of ticket 2608. Similarly, the 
clone of agent 150A corresponding to ticket 2610 retrieves the string "Baker" from property "travelNotes" of 
ticket 2610. 

The particular implementation by which the respective clones are distinguished is ultimately up to the user 
20 of the present inventton. The following is another example. Stored within object 261 8 is an integer whose value 
is one, thereby representing the position of corresponding ticket 2608 within list 2606. Similarly, stored within 
object 2620 is an integer whose value is two, thereby representing the position of coTOsponding ticket 2610 
within list 2606. 

Permits 2622 and 2624 are properties "destinationPermir of tickets 2608 and 2610, respectively. Integers 

25 2626 and 2628 are properties "charges" of permits 2622 and 2624. respectively. 

Permit 2612 is property "permit" of agent 1 SOAand therefore represents a part of the internal state of agent 
150A. As described above and in Appendix A. permit 2612 limits the execution of agent 150A. Boolean 2614 
is property "canSend" of permit 2612. If the value of boolean 2614 is "false", operation "send" fails and throws 
an exception of class "Permit Violated". Property "charges" of permit 2812 is integer 2616. As discussed in 

30 greater detail in Appendix A, integer 2616 represents the processing allowance of agent 150A. 

In the example of Figure 25. agent 150A, whose current location is place 220A, is configured to transport 
respectwe clones of agent 150Ato places 220B and 220C. As agent 150A sends a done of itself to each des- 
tinatran place defined by a ticket in list 2606 (Figure 26 A), performance of operation "send" eventually creates 
as many dones of agent ISOAas there are tickets in list 2606. Figures 27Aand 27B illustrate a simple em- 

35 bodiment of operation "send" wherein engine 132A (Figure 27A) creates within data portton 1 32A-D a number 
of dones of agent 150A equal to the number of tickets in list 2606 (Figure 26A). In this example, list 2606 (Figure 
26A) contains two tickets, i.e., tickets 2608 and 261 0. Therefore, engine 1 32A creates two dones, agent 1 50A- 
1 and agent 150A-2. of agent 1 50A (Figure 27B). A more efficient embodiment, in which doning of the respond- 
ing agent is deferred, is described below. 

40 In forming the dones of agent 1 50A, permits 2622 and 2624 are made property "peoniT of the dones cre- 

ated. In other words, permit 2622 is property "permit" of agent 150A-1 and permit 2624 is property "permit" of 
agent 1 50Ar2. In creating agents 1 50A-1 and 1 50A-2, the allowances of permits 2622 and 2624 are subtracted 
from the corresponding allowances of permit 2612 of agent 1 50A, i.e.. the agent that is being cloned. In other 
words, the value of integere 2626 and 2628 are subtracted from integer 261 6, which is the charges allowance 

46 of agent 150A, i.e.. property "charges" of the permit of agent 150A. upon creation of agents 150A-1 and 150A- 
2. If integer 2616 is not greater than or equal to the sum of integers 2626 and 2628, operation "send" foils and 
throws an exception of dass "Permit Vfolated" since the charges allowance of agent 1 50A is less than the sum 
of the charges allowances of the dones created from agent 1 50A. 

Thus, the permits which are part of the tickets supplied as aiiguments to operation "send" form the native 

so permits of the dones created in performance of operation "send". As tickets 2608 and 2610 define trips to be 
taken by respective dones of agent 150A. penmits 2622 and 2624 are property "permir of tickets 2608 and 
2610, respective, and are therefore also the local permits of respective dones of responding agent 150A. 

In a second embodiment of the present invention, operation "send" consumes, as an argument in addition 
to list 2606, an integer (not shown). In creating dones of responding agent 150A, respective native penmits 

)5 are formed as described above with the exceptton that property "charges" of each native permit is initially equal 
to the integer consumed. 

A third embodiment of the present invention is the same as the second embodiment described above with 
the exception that a list of integere is consumed in lieu of a single integer. Additionally, property "charges" of 
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each native permit, which is derived from property "permit" of a ticket within list 2606 (Figure 26A), is initially 
equal to the integer at a position within the consumed list of integers that is equal to the position within list 
2606 of the ticket from which the native permit is derived. For example, property "charges" of the native permit 
of the clone con-esponding to ticket 2608 at position one within list 2606 is initially equal to the integer at position 
5 one in the consumed list of integers (not shown). Similarly, property "charges" of the native permit of the done 
corresponding to ticket 2610 at position two within list 2606 is initially equal to the integer at position two in 
the consumed list of integers. 

In a fourth embodiment of the present Invention, operation "send" consumes, as an argument in addition 
to list 2606, a permit (not shown). In creating clones of responding agent 150A, each respective native permit 
10 is a copy of the consumed permit 

A fifth embodiment of the present invention is the same as the fourth embodiment described above with 
the exception that a list of permits is consumed in lieu of a single permit. Additionally, each native permit of a 
respective clone corresponding to a ticket within list 2606 (Figure 26A) is initially equal to the permit at a position 
within the consumed list of permits that is equal to the position within list 2606 of the ticket to which the done 
IS corresponds. For example, the native permit of the clone corresponding to ticket 2608 at positton one within 
list 2606 is initially equal to the permit at position one in the consumed list of permits (not shown). Similarly, 
the native permit of the clone corresponding to ticket 2610 at position two within list 2606 is initially equal to 
the permit at positbn two in the consumed list of permits. 

In each of the described embodiments, property "charges" of permit 2612, which is the permit of respond- 
20 ing agent 1 50A, is reduced by the total of respective properties "charges" of the native permits of the clones 
of agent 150A created in performance of operation "send". 

Each done of agent 150A is transported to a place ident'fied by the corresponding ticket as a destination 
place. For example, ticket 2608 identifies place 220B as the destinatton for agent 1 50A- 1 , and ticket 261 0 iden- 
tifies place 220C as the destination for agent 150A-2. Each clone travels to its respective destination place 
25 through the cooperation of the source engine 132A with a corresponding destination engine, e.g., either engine 
132B or engine 132C. The transportation of an agent clone, e.g. either agent 150A-1 or agent 150A-2. from 
one place to another in performing operation "send" is as described above in detail in conjunction with operation 
"go". 

If, in performance of operatton "send", agent 150A successfully creates agents 150A-1 and 150A-2, per- 
30 formance of operation "send" by agent 1 50A succeeds even if the transportation of any or all of the agent clones 
fails. If a trip of an agent done fails, the trip exception is thrown by the agent done, not the agent which originally 
performed operation "send". 

A portion of the execution state of agent 150A immediately following performance of operatton "send" by 
agent 1 50A is shown in Figure 26B. Stack 2604. which is the current stack as described above, contains a nil 
35 object 2630. A nil object Is produced as a result for the original agent, thereby distinguishing the original agent 
from agent dones created In performance of operation "send". 

Figure 26C shows a portion of the execution state of agent 150A-1 after performance of operation "send" 
by agent 150A. The executton state of agent 150A-2 after performance of operation "send" by agent 150A is 
directly analogous to the execution state of agent 150A-1 as described immediately below. 
« Permit 2622 is property "permiT of agent 150A-1. Stack 2604-1 is a copy of stack 2604 produced in the 

creation of agent 1 50A-1 . Stack 2604-1 is the current stack of agent 1 50A-1 . At the top of stack 2604-1 is ticket 
stub 2632. Ticket stub 2632 is the result produced by operation "send" for an agent done created by perfor- 
mance of operation "send". Ticket stub 2632 is derived from ticket 2608. 

Ticket stub 2632 is a member of a dass "Ticket Stub". Ticket stub 2632 has. among other properties, prop- 
46 erties "way" and "travelNotes". Tlcket2608 is a member of a dass Ticket". Class Ticker is a subdass of dass 
Ticket Stub"; therefore, ticket 2608 has, among other properties, properties "way" and "travelNotes", defini- 
tions of which are inherited from superdass Ticket Stub". Ticket stub 2632 is derived from ticket 2608 such 
that properties "way" and "travelNotes" of ticket stub 2632 are equal to properties "way" and "travelNotes", 
respectively, of ticket 2608. As discussed above, property "travelNotes" of ticket 2608 (Figure 26A) can be used 
so to distinguish agent 1 SOA-I from agent 1 50A-2. Similarly, the current stack (not shown) of agent 1 50A-2 con- 
tains a ticket stub (not shown) whose property "travel Notes" is object 2620. 

Figure 28 shows computer network 2500 after operation "send" has been performed by agent 1 50A. Agent 
150A remains in data portion 132A-D of computer process engine 132A. Agent 150A-1 occupies place 220B 
in data portion 132B-D of engine 132B. Similarly, agent 150A-2 occupies place 220C executing in data portion 
ss 132C.D of engine 132C. 

The access of operatran "send" is "private" penmitting only the responder to request the operatton. As dis- 
cussed in greater detail below and in Appendix A, each feature of the present inventton has an access which 
specifies under what conditions the feature can be requested. As the access of operation "send" is private, 
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only agent 150Acan initiate performance of operation "send" by agent 150A. Even engine 132A cannot initiate 
performance of operation "send" by agent 150A. 

Deferred Cloning 

5 

Substantial savings in the amount of time required to perform operation "send" and in space occupied by 
clones of an agent created during performance of operation "send" are realized by "deferred cloning". Deferred 
cloning occurs when the engine carrying out performance of operation "send" determines that two or more 
clones of the same agent are to be transferred to a single destination engine. In such a case, a single done 

10 is transferred to the destination engine and additional dones are derived from the single done at the destin- 
ation engine. Figures 29A-29D are illustrative. 

Agent 150A (Figure 29A) occupies place 220A in engine 132A. Engine 132A is a computer process exe- 
cuting within computer system 110A (not shown). Agent ISOAis performing operation "send", supplying as the 
argument to the operation a list of three tickets (not shown) specifying places 220B. 220C and 220D as des- 

15 tination places for dones of agent 150A, Engine 132A is in comnrujnication with engine 132E across commu- 
nications link 102AE. Communk^tions link 102AE is as described above with respect to communications link 
102AZ (Figure 15A) in conjunction with operation "go". In addition to engine 132A, engine 132E is in commu- 
nication with engines 132B and 132F across communications link 102EBF. Additionally, engine 132F is in com- 
munication with engines 132C and 132D across communications link 102FCD. Places 2208, 220C and 220D 

20 are processes interpreted by engines 1 328, 1 32C and 1 32D» respectively. Thus, for dones of agent 1 60A to 
reach places 2208, 220C and 220D, each done must first be transfen-ed to engine 132E. 

Created within engine 132A is a single done, i.e., agent 150A-1, of agent 150A. The execution state of 
agent 1 50A-1 indudes a send frame 2902 as agent 1 50A-1 Is performing operation "send". The execution state 
of an agent is discussed in greater detail below and in Appendix A. Send f ranges are discussed In greater detail 

25 in Appendix 8. Send frame 2902 (Figure 30A) Includes list of tickets 2904 which indudes tickets 2904B, 2904C 
and 2904D which in turn specify places 2208, 220C and 220D, respectively, as destination places. Agent 
150A-1 (Figure 29A), the single clone of agent 150A. therefore represents three separate agent dones which 
are to travel to places 2208, 220C and 220D, respectively. 

Encoded agent 150A-1-E (Figure 308) is the result of encoding agent 160A-1 (Figure 29A) according to 

30 the encoding rules of Appendix B. Induded in encoded agent 150A-1-E (Figure 308) are destinations 150A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 which define respective transfer destinations of the three dones of 
agent 1 50A (Figure 29A). As alt three dones of agent 1 50A are transferred to engine 1 32E, destinations 1 50A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 (Figure 308) all define engine 132E as the transfer destination of a 
respective clone of agent 150A (Figure 29A). Engine 132A determines that destinations 150A-1-E-D1, 150A- 

35 1-E-D2, and 150A-1-E-D3 (Figure 308) each define engine 132E as a transfer destination and transfers a sin- 
gle done of agent 150A (Figure 29A), i.e., encoded agent 150A-1-E (Figure 308) to engine 132E (Figure 298). 
Thus, rather than transporting three separate dones from engine 1 32A to engine 1 32E, a single clone Is trans- 
ported to engine 132E reducing proportionally the amount of space within engine 132A occupied by dones of 
agent 150A and the anDount of time required to transport clones to engine 132E. 

40 Agent 1 50A-1 is encoded and transferred to engine 1 32E (Figure 298) as discussed above in conjunction 
with operation "go". Engine 1 32E retrieves list 2904 of send frame 2902 of agent 1 50A-1 . As the structure of 
an encoded agent is standardized as described in Appendix 8, an engine, e.g., engine 132E, can retrieve list 
2904 without decoding encoded agent 150A-1. Engine 132Edetenmine3 that one done corresponding to ticket 
29048 of send frame 2902 is to be transported to engine 1328 and that two dones conresponding to tickets 

45 2904C and 2904D are to be transported through engine 1 32F to engines 1 32C and 1 32D, respectively. There- 
fore, a second done, agent 1 50A-2 (Figure 29C), is created from agent 1 60A-1 by engine 1 32E. As agent 1 50A- 
1 is encoded, agent 150A-2, which is a copy of agent 150A-1, is encoded as well. Agent 150A-2 indudes send 
frame 2902-2, and send frame 2902-2 In turn indudes list of tickets 2904-2. List of tickets 2904-2 indudes a 
singJe ticket 29048 whk:h is removed from list of tickets 2904 of send frame 2902 of agent 150A-1. 

50 Agent 1 50A-2 is transferred to engine 1328, and agent 150A-1 is transferred to engine 132F (Figure 29D). 
As ticket 2904B specifies place 2208 as the destination of a trip and ticket 29048 Is the only ticket in send 
frame 2902-2, place 2208 is the destination of agent 1 50A-2 and no further dones of agent 1 50A are created 
from agent 150A-2. Agent 150A-2 is decoded by engine 1328. Agent 150A-2 ts granted occupancy to place 
2208 by performance of operation "entering" by place 2208 as described above, and perfonnnance of operation 
55 "send" for agent 150A-2 is completed. Send frame 29028 is therefore rennoved from the execution state of 
agent 150A-2 as discussed tielow in the context of the executk>n model 

Agent 150A-1 is transferred to engine 132F. Induded in send frame 2902. which Is part of the execution 
state of agent 1 50A-1 , is list of tickets 2904 which in turn indudes tickets 2904C and 2904D. Thus, agent 1 50A- 
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1 represents two clones of agent 150A which are traveling to places 220C and 220D, respectively. Therefore, 
by transferring a single done, i.e. agent 150A-1, from engine 132E to engine 132F, substantial savings are 
realized in storage space in engine 132E and in time required to transport data between engine 132E and en- 
gine 132F as described above. 

5 In the manner described above, in engine 132F (i) a third done of agent 150A, i.e., agent 150A-3, is formed 

from agent 150A-1. and (ii) a send frame (not shown) is included in agent 150A-3 which indudes ticket 2904C. 
As agent 150A-1, from which agent 150A-3 is copied. Is encoded, agent 160A-3 is encoded as well. Ticket 
2904C is removed from send frame 2902 of agent 150A-1. Agent 150A-3 is transferred to engine 132C, and 
agent 150Ar1 is transferred to engine 132D (Figure 29E). 

10 Engine 132C Indudes place 220C which is the trip destination of agent 150A-3 as defined by ticket 2904C, 

and engine 132D indudes place 220D which is the trip destination of agent 1 50A-1 as defined by ticket 2904D. 
In the manner described above, (i) engine 132C decodes agent 1 50A-3 and agent 1 50A-3 is granted occupancy 
of place 220C by performance of operation "entering" and (ii) engine 132D decodes agent 150A-1 and agent 
1 50A-1 is granted occupancy of place 220D by performance of operation "entering". Since send frame 2902 

15 (not shown) contains only a single ticket which spedf ies place 220D as the destination, operation "send" com- 
pletes for agent 150A-1. Similarly, as agent 150A-3 includes a send frame specifying a single place, namely, 
place 220C which is the place occupied by agent 150A-3, as the destination of a trip, operation "send" com- 
pletes for agent 150A-3 as well. 

Each of agents 150A-1, 150A-2 and 150A-3 completes performance of operation "send" having an exe- 

20 cution state which includes a send frame which includes a single ticket which defines the trip taken by the re- 
spective agent clone. The respective single ticket is used as described above to derive a ticket stub which is 
produced as the result of the respective agenf s performance of operation "sond". 

Thus, substantial amounts of computer storage space and time are saved in performance of operatton 
"send" by deferring doning as long as possible in the transportatton of the several dones to respective des- 

25 tinatfon places. 

The structure of send frame 2902 during transport of agent 150A-i is shown in Figure 30. Class "Send 
Frame" defines property "tickets". Property "tickets" of send frame 2902 is list 2904 whose items are tickets 
2904B. 2904C and 2904D. Tickets 2904B. 2904C and 2904D define respective trips to be taken by respective 
clones of responding agent 150A. 

30 As discussed above, performance of operation "send" by agent 150A creates one or more agent dones, 

each agent done representing one or more dones of agent 1 50A. If forming each agent done, e.g. agent 1 50A- 
1 (Figure 29A), a copy of send frame 2902 is induded in the agent done. Property "tickets" of the send frame 
copy is modified so as to indude only those tickets corresponding to the clones represented by the agent done. 
For example, agent 150A-2 (Figure 29C) indudes send frame 2902-2 which in turn indudes ticket 2904B and 

35 agent 150A-1 indudes send frame 2902 which In turn indudes tickets 2904C and 2904D. Therefore, agent 
1 50A-2 represents a single done of agent 1 50A which is traveling to the place specified by ticket 29048. name- 
ly, place 220B. Similarly, agent 150A-1 represents two dones of agent 150A which are traveling to places spe- 
cified by tickets 2904C and 2904D. namely, places 220C and 220D. respectively. 

Once each clone has reached its respective destination, property "tickets" of send frame 2902 (Figure 

40 30) is a list of exactly one ticket For example, agents 150A-1. 150A-2 and 150A-3 (Figure 29E) indude send 
frames 2902, 2902-2 and 2902-3. respectively, which each indude a single ticket, namely, respective tickets 
2904D, 2904B and 2904C. Thus, each send frame contains the single ticket defining the trip taken by the cor- 
responding agent done. The single ticket is used as described above to form a ticket stub which is produced 
as a result by performance of operatksn "send" by each respective agent done. 

45 Thus, substantial savings are realized in computer storage space and data transportatton time by defening 

cloning of an agent performing operation "send" as long as two or more agent dones are taking trips which 
are coextensive in part As described above in the context of operation "go", if an exception is thrown during 
performance of operation "go" by an agent, the agent can be placed in purgatory. Similarly, if an exception is 
thrown during performance of operation "send" by an agent done, the agent clone can be placed in purgatory. 

so Additionally, if transportatk>n of multiple dones of an agent which are represented by a single encoded agent, 
e.g. agent 150A-1 (Figure 29B). fails, each done represented by the encoded agent is decoded, activated, and 
placed in purgatory as described above. 

Interactton Between Agents: Operation "Meet" 

55 

Two agents, which occupy the same place, are capable of interacting with one another by one agent re- 
questing that the other perform an operation, or set or query an attribute. Infonnation is exchanged between 
the two agents through the arguments and result of the operation requested or through the attribute which is 
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set or queried. For example, agent 150Aand 150B occupy place 220B which is executing within engine 132B 
(Figure 15E). Therefore, agent 150A and agent 150B are capable of interacting by (i) agent 150A requesting 
that agent 150B perform a feature or by (ii) agent 150B requesting that agent 150A perform a feature. 

Agent 1 50A is capable of requesting that agent 1 SOB porfomi a featufe only if agent 1 50A contains a ref- 
5 erence to agent 1508. Similarly, agent 150B is capable of requesting that agent 150A perform a feature only 
if agent 150B contains a reference to agent 150A. Agent 150A obtains a reference to agent 150B by requesting 
performance of operation "meet" by a meeting place of which agents 150Aand 150B are occupants. To this 
point place 220B has only been described as a place occupied by agents 150A and 150B. For purposes of 
the following discussion, place 220B is a meeting place, i.e.. a member of class "Meeting Place". Meeting places 
10 are discussed in more detail In Appendbc A- 

Figures 31 A and 31 B illustrate the interface of operation "meet". Frame 3100 is part of the execution state 
of agent 150A. Frame 31 00 records the state of the perfonmance of operation "meer by meeting place 220B. 
Meeting place 220B is identified within the execution state of agent 1 50A as the responder of operation "meet". 

Frame 3100 Includes stack 3102. which is the current stack. Immediately prior to performance of operation 
15 "meer (Figure 31A), stack 3102 contains, at its top, petition 3106. Petition 3106 is an argument consumed by 
performance of operation "meer. Petitions, i.e. nrmmbers of class "Petitfon", are discussed more completely 
below and In Appendbc A. 

Logic flow diagram 3200 (Figure 32) shows the impiementation of operation "meer as performed by meet- 
ing place 220B. Engine 132B (Figure 15E). in carrying out operation "meer as performed by meeting place 

20 220B, detenmines the petitioned agent by parsing petition 3106 (Figure 31A). Petition 3106 specifies a peti- 
tioned agent by name, by class or by both. A petitioned agent is an agent specified by a petition as the agent 
with which an agent requesting a meeting is configured to meet 

Engine 132B pops petitton 3106 from the current stack in a pop petition step 3202 (Figure 32); Processing 
transfers from pop petition step 3202 to a step 3204. In step 3204. engine 132B creates a new, empty list of 

25 telenanrwa. The telenan^es of the list created in step 3204 are tetenames of petitbned agents which have re- 
jected a meeting with the requesting agent The list is initially empty as initially no petitioned agent has rejected 
a meeting with the requesting agent 

Processing transfers from step 3204 to a find petitioned agent step 3206 in which the engine carrying out 
performance of operation "meer. e.g.. engine 132B (Figure 15E), finds a petitioned agent i.e.. an agent which 

30 satisfies petition 3106 (Figure 31 A), whose telename is not an item of the list of telenames created in step 3204 
(Figure 32). An agent satisfies petition 3106 (Figure 31 A) as follows. 

As described in greater detail in Appendbc A, petition 3106 includes a property "agentName" and a property 
"agentOass" (neither shown). Both properties "agentName" and "agentClass" are optional and can therefore 
each be a nil. If property "agentName" of petition 3106 is a telename and property "agentDass" is nil. a peti- 

35 tioned agent is an agent whose telename is specified by the telename that is property "agentName" of petition 
3106. If property "agentQass" is a citation and property "agentName" is nil, a petitioned agent is an agent which 
is a member of a dass specified by the citation that is property "agentClass" of petition 31 06. If neither property 
is nil, a petittoned agent is an agent which satisfies both criteria. If both properties are nil. an exception of dass 
"MBeting Invalid" is thrown, causing operatron "meer to fail. 

40 Processing transfers from find petittoned agent step 3206 to test step 3208 In which engine 132B deter- 
mines whether a petitioned agent is found in find petition agent step 3206. If no petitioned agent is found in 
find petitioned agent step 3206, processing transfersf rom test step 3208 to a wait step 3222 which is described 
below. Conversely, if a petitioned agent is found in find petitioned agent step 3206, processing transfers from 
test step 3208 to a meeting step 321 0. 

<5 In meeting step 3210, the petitioned agent is requested to perform operation "meeting" by engine 132B 

which is interpreting meeting place 220B. In perfbnming operation "meeting", the petitioned agent agrees or 
refuses to participate in a meeting with agent 150A. Operation "meeting" is dbcussed further below and in 
Appendbc A. 

After performance of operation "meeting" by the petitioned agent processing transfers from meeting step 
50 3210 to test step 321Z In test step 3212, engine 1 32B determines whether operation "meeting" completed suc- 

cessf uUy, indicating that the petitioned agent agrees to the meeting. If the petitioned agent refuses the meeting. 

i.e.. processing transfers from test step 3212 to a first fully qualified test step 3234. which is described below. 

Conversely, if the petitioned agent agrees to the meeting, i.e., if operation "meeting" completed successfully. 

processing transfera from test step 3212 to a build contact step 3216. 
5 In build contact step 321 6. a contact 31 08 (Figure 31 B). whose subject is the petitioned agent is created. 

Processing transfers from build contact step 3216 (Figure 32) to a push contact step 3218 in which contact 

3108 (Figure 31 B) is pushed on to stack 3102, thereby producing contact 3108 as a result Processing transfers 

from push contact step 3218 to tenminal step 3220 in which operation "meer completes successfully. 
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However, as discussed above, if the petitioned agent throws an exception In perfonmance of operation 
"meeting", thereby refusing to meet with agent 150A, processing transfers from test step 3212 to first fully 
qualified test step 3234. In first fully qualified test step 3234. engine 132B determines whether petition 3106 
(Figure 31 A) is fully qualified. Petition 3106 is fully qualified if the telename that is property "agentName" of 

5 petition 3106 is fully qualified. A telename includes both a property "authority* and a property "identity". Tel- 
enames are described more completely in Appendix A. Property "identity" of a telename is optional, i.e.. can 
be a nil. If property "identity" of a telename is nil. the telename is partially qualified and denotes all named 
objects of the authority that Is property "authority" of the telename. On the other hand, if property "identity" 
of a telename Is not nil, the telename is fully qualified and denotes exactly zero or one named object 

10 In first fully qualified test step 3234 (Figure 32). engine 132B determines whether petition 3106 (Figure 

31 A) is fully qualified. If petition 3106 (Figure 31 A) is fully qualified, processing transfers from first fully quali- 
fied test step 3234 to terminal step 3236 in which an exception of class "Meeting Denied" Is thrown, causing 
operation "meer to fail. Thus, if petition 3106 (Figure 31A) is fully qualified and the one agent which satisfies 
petition 3106 rejects the meeting, operation "meet" fails. On the other hand, if petition 3106 is not fully qualified. 

15 processing transfers from first fully qualified test step 3234 to an add agent to list step 3214. 

In add agent to list step 3214, the petitioned agent found in find petitioned agent step 3206 Is added to 
the list of telenames created in step 3204. Processing transfers from add agent to list step 3214 to find peti- 
tioned agent step 32(^. 

As discussed above, if no petitioned agent is found in find petitioned agent step 3206. processing transfers 
20 from test step 3208 to wait step 3222. In wait step 3222. interpretation of agent 1 50A is suspended until petition 
3106 (Figure 31 A) expires or until an agent enters meeting place 220B, i.e., until meeting place 220B success- 
fully performs operation "entering". As described more completely in Appendix A. petition 31 OC includes a prop- 
erty "maximumWait" which defines a maximum amount of time that can elapse from the start of performance 
of operation "meet" before operation "meet" must conclude, either successfully or otherwise. Petition 31 06 ex- 
25 pires when the anrrountof time specified In property "maximumWair has passed since the start of performance 
of operation "wair. 

When petition 31 06 expires or when an agent enters meeting place 220B, interpretation of agent 1 50A re- 
sumes and processing transfers from wait step 3222 (Figure 32) to a timeout test step 3224. In timeout test 
step 3224, engine 1 32B (Figure 1 5E) determines whether resumption of interpretation of agent 1 50A (Figure 

30 31A) results from expiration of petition 3106. If interpretation of agent 150A is resumed as a result of the ex- 
piration of petition 3106 (Figure 31 A), processing transfers from timeout test step 3224 (Figure 32) to terminal 
step 3226 in which an exception of dass "Petition Expired" is thrown, causing operation "meer to fail. 

On the other hand, if interpretation of agent 150A (Figure 31 A) is resumed as a result of an agent entering 
place 220B, processing transfers from timeout step 3224 to test step 3228. In test step 3228. engine 132B 

35 (Figure 1 5E) determines whether the entering agent (not shown) is petitioned, i.e., satisfies petition 3106 (Fig- 
ure 31 A), and is not on the list of telenames created in step 3204 (Figure 32) . If the entering agent does not 
satisfy petition 3106 (Figure 31 A) or if the telename of the entering agent Is an item of the list of telenames 
created in step 3204 (Figure 32). processing transfers from test step 3228 to wait step 3222. 

If. on the other hand, the entering agent satisfies petition 3106 (Figure 31 A) and the telename of the en- 

40 tering agent is not an Item of the list of telenames created In step 3204 (Figure 32), processing transfers from 
test step 3228 to a second meeting step 3230. In second meeting step 3230, the entering agent is directed to 
perform operation "meeting". Processing transfers from second meeting step 3230 to test step 3232 in which 
engine 132B (Figure 1 5E) determines whether performance of operation "meeting" by the entering agent suc- 
ceeded, the entering agent thereby accepting a meeting with agent 1 50A. or failed, the entering agent thereby 

45 rejecting a meeting with agent 150A. 

If perfonmance of operation "meeting" by the entering agent succeeds, processing transfers from test step 
3232 to build contact step 3216. As described above, in build contact step 3216 and the steps that follow, a 
contact to the petitioned. I.e., entering, agent is built, the contact Is pushed on to the current stack, and operation 
"meer completes successfully. If, on the other hand, performance of operation "meeting" by the entering agent 

50 throws an exception, processing transfers from test step 3232 to a second fully qualified test step 3238. 

In second fully qualified test step 3238. engine 132B (Figure 15E) detennines whether petition 3106 (Fig- 
ure 31 A) is fully qualified. If petition 3106 is fully qualified, processing transfers from second fully qualified 
test step 3238 (Figure 32) to tenminal step 3240 in which an exception of dass "Meeting Denied" is thrown, 
causing operation "meet" as performed by meeting place 220B to fail. 

55 Conversely, if petition 3106 (Figure 31A) is notfully qualified, processing transfers from second fully quali- 

fied test step 3238 to a second add agent to list step 3242. In second add agent to list step 3242. the telename 
of the petitioned, i.e., entering, agent is added to the list of telenames created in step 3204. Processing transfere 
from second add agent to list step 3242 to wait step 3222 which is described above. 
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Thus, a meeting is arranged between agent 150Aand a petitioned agent (i) which is of the name and dass 
specified by petition 3106. (ii) which occupies the responding meeting place, and (iii) which agrees to the meet- 
ing within the maximum time period specified in petition 3106. The last condition permits a first agent to request 
a meeting with a second agent which does not occupy the meeting place occupied by the first agent but which 
5 is expected to arrive at the meeting place within a certain amount of time. 

Immediately following performance of operation "meer (Figure 31 B), stack 3102 contains, at its top, con- 
tact 3108. as described above. Contact 3108 includes a property "subjecf which i3 a reference to agent 'l SOB 
(Figure 15E). Property "subjecT of contact 3108 (Figure 31 B) is produced by querying attribute "subjecT of 
contact 3108. Attribute "subjecT of a contact is described in greater detail in Appendix A. Thus, agent 150A 
10 obtains a reference to agent 1 508 (Figure 1 5E) and is therefore capable of requesting that agent 1 SOB perform 
features. 

As discussed below in the context of operation "meeting", agent 150B consumes, as an argument in per- 
formance of operation "meeting", a contact which identifies agent 1S0A as the agent requesting a meeting. 
After performance of operation "meer by meeting place 220B, the contact consumed by agent 1 SOB includes 

15 a property "subjecT which is a reference to agent 150A. Thus, agent 150B obtains a reference to agent 150A 
and Is capable of requesting that agent 150A perform features. 

An agent, which is contacted, is a number of a class which inherits from mix-in dass "Contacted". As de- 
scribed more fully in Appendix A below, mix-in dass "Contacted" defines attribute "contacts" which provides 
access to property "contacts". Property "contacts" is a set of contacts. Agent 150B (Figure 33) is a contacted 

20 agent and therefore indudes property "contacts", which is set 3302. After perfomiance of operation "meet" by 
meeting place 220B as described above, contact 3404. which is the contact consumed in performance of op- 
eration "meeting" by agent 1 SOB, is added to set 3302 by engine 1 32B. 

Consent of the Petitioned Agent Operation "Meeting" 

25 

As discussed above, a petitioned agent agrees or refuses to meet with an agent requesting a meeting by 
performance of operation "meeting" by the petitioned agent Operation "meeting" is not defined or inherited 
by dass "Agent". Instead, operation "meeting" is defined by mix-in class "Petitioned". Class "Agent" Is not a 
subdass of mix-in dass "Petittoned". but subdasses of dass "Agent", which are subsequently defined by users 
30 of the present invention, can be subdasses of mix-in dass "Petitioned". Thus, only agents which are members 
of such user-defined subdasses can perform operation "meeting" and can therefore participate in meetings 
with other agents. 

Figure 34A shows the execution state of agent 1 SOA immediately prior to perfomnance of operation "meet- 
ing" by agent 1S0B. Frame 3400 ts a part of the execution state of agent 1S0A and records the dynamic state 
35 of operation "meeting" as perfonned by agent 150B. Operation "meeting" is requested by engine 132B; the 
performance of "meeting" is recorded in the execution state of agent 150A. The permit of either agent 150A 
or agent 1S0B, perferabiy agent 1S0B. may be debited by performance of operation "meeting". Agent 1S0B 
(Figure 1SE) is identified within engine 132B as the responder of operation "meeting". 

Stack 3402 is property "stack" of frame 3400 and is the current stack. Immediately prior to performance 
40 of operation "meeting", stack 3402 contains, from top to bottom, contact 3404 and petition 3406. 

Contact 3404 identifies agent 1S0A as the agent requesting a meeting. Property "subjectName" (not 
shown) of contact 3404 is a telename which is equivalent to the telename of agent 150A, thereby identifying 
agent 1S0A as the requesting agent Property "subjectClass" (not shown) of contact 3404 is a dtation identi- 
fying the dass of which agent 150A is an instance. Property "subject" (not shown) of contact 3404. which is 
46 normally a reference to agent 1 SOA, is nnade nil by engine 1 32B, Thus, agent 1 SOB. by consuming contact 3404 
in perfonmance of operation "meeting", has all the information necessary to properly identify agent 1 SOA as 
the agent requesting the meeting, but has no reference to agent 1S0A and therefore has no way to Interact 
with agent 1S0A. In this way, neither agent can interact with the other until both have agreed to the meeting. 
Petition 3406 is a copy of petition 3106 (Figure 31 A) supplied by agent 150A (Figure 15E) in requesting 
so the meeting, as this argument is passed "byCopy". Passing an argunwnt "byCopy" is discussed in greater detail 
below and in Appendbc A. 

Agent 1S0B agrees to the meeting defined by petition 3406 (Figure 34A) with the agent identified by con- 
tact 3404 by performing operation "meeting" successfully. The meeting is refused by throwing an exception, 
thereby causing operation "meeting" to fail. The method for operation "meeting", as defined by mix-in dass 
55 "Petitioned", never succeeds and always throws an exception of dass "Meeting Denied". However, subse- 
quently defined subdasses of dass "Agenr. which inherit from mix-in dass "Petitioned" can redefine the inrv 
plementation of operation "meeting" so as to succeed under certain circumstances. 

Since agents are anticipated to serve a wide variety of needs and to perform a wide variety of services, 
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the number of subclasses of dass "Agent" and the variations of methods fbroperation "meeting" are quite large. 
For example, logic flow diagram 3500 (Figure 35) shows one such method for operation "meeting". In step 3502, 
contact 3404 (Figure 34A) and petition 3406 are popped from stack 3402. Processing transfers from step 3502 
(Figure 35) to step 3504 in which attribute "subjectClass" of contact 3404 (Figure 34A) is queried, thereby pro- 
5 ducing property "subjectClass" of contact 3404. Processing transfers from step 3504 (Figure 35) to a test step 
3506, in which property "subjectClass" of contact 3404 (Figure 34A) is compared to the citation of a specific 
class. If property "subjectClass" of contact 3404 is equal to the citation, processing transfers from test step 
3506 (Figure 35) to terminal step 3508. In terminal step 3508, operation "meeting" completes successfully and 
the meeting is thereby agreed to. Otherwise, if property "subjectClass" of contact 3404 (Figure 34) is not equal 
10 to the citation, processing transfers from test step 3506 (Figure 35) to temiinal step 3510 In which an exception 
of dass "Meeting Denied" is thrown causing operation "meeting" to fail, thereby rejecting a meeting with the 
agent identified by contact 3404 (Figure 34A). 

As discussed above, contact 3404. which identifies agent 150A and is supplied to agent 150B (Figure 15E) 
as an argument in requesting performance of operation "meeting", contains no reference to agent 150A. In- 
15 stead, property "subjecT of contact 3404 (Figure 34A) is nil. Once a meeting is successfully arranged by per- 
formance of operation "meet" by meeting place 220B (Figure 15E) as described above, engine 132& modifies 
property "subjecf of contact 3404 (Figure 34A) to be a reference to agent 15QA. 

Thus, the full generality and data processing capabilities of the computer instruction set described in Ap- 
pendix A can be used to apply sophisticated logic, processing substantial amounts of data, to determine with 
20 which agents and under what circumstances specif ic agents are configured to agree to a meeting. 

Figure 34 B shows the state of frame 3400 immediately following performance of operation "meeting" by 
agent 150B (Figure 15E). Stack 3402 (Figure 348) is empty as operation "meeting" produces no result The 
access of operation "meeting" is "system"; only an engine is capable of requesting operation "meeting". It 
should be noted that operation "meeting" defined by mix-in dass "Petitioned" is distinct and separate from op- 
25 eration "meet" defined by dass "Meeting Race" which is discussed above and in Appendix A. 

Terminating Interaction Between Agents: Operation "Part" 

As described above, two agents exchange references to each other and to objects owned by either agent 

30 during the course of a meeting between the two agents. Terminating Interaction between the agents requires 
ensuring that neither agent contains a reference to the other agent or references to objects owned by the other 
agent. Either agent participating in a meeting between two agents occupying a meeting place can terminate 
the meeting by requesting performance of operation "parT by the meeting place. Agents 1 50A and 1 50B which 
occupy meeting place 220B and which are Interpreted by engine 132B (Figure 15E), are shown in Figure 36. 

35 Agent 150A has obtained reference 150A-R1 to agent 150B. and agent 150B has obtained reference 1508- 
R1 to agent 150A. by the successful performance of operation "meet" by meeting place 2208. Object 3602 is 
owned by agent 150A. Similarly, object 3604 is owned by agent 1508. Figure 36 shows the state of agents 
150A and 150B after agents 150A and 150B have interacted and exchanged references to objects 3602 and 
3604. By giving to agent 1508 a reference to object 3602. agent 150A grants agent 1508 access to object 3602. 

40 Such access by references 1508-R1 and 1508-R2 enables agent 1508 to issue instructions to engine 1328 
which cause agent 150A and object 3602. respectively, to take action in accordance with the instructions is- 
sued. Similarly, agent 1508 gives to agent 150A reference 150A-R2 to object 3604. thereby granting to agent 
1 50A similar access to object 3604. 

Agent 150A contains references 150A-R1, 150A-R2 and 150A-R3 to agent 150B. object 3604. and object 

45 3602. respectively. References 1 50A-R1 , 1 50A-R2 and 1 50A-R3 are (i) contained either within a stack or within 
a list of variables (neither shown) of a frame (also not shown) which is part of the execution state of agent 1 50A 
or (ii) stored as a property, or as a component of a property, of agent 150A. The execution state of an agent 
is discussed in detail below. Agent 1508 similarly contains references 1508-R1. 1508-R2 and 150B-R3 to 
agent 1 50A. object 3602. and object 3604, respectively. By giving to agent 1 50A reference 1 50A-R2 to object 

SO 3604. agent 1 508 allows agent 1 50A (i) to request that object 3604 perform an operatnn or (ii) to copy a portion 
or ail of object 3604. 

Either agent 150A or agent 1 SOB is capable of terminating the interaction between agents 150A and 1508 
by requesting that meeting place 2208 perform operation "part". For illustration purposes, agent ISOAis the 
agent which requests that meeting place 220B perform operation "part". Figures 37A and 37B illustrate the 
5$ state of agent 1 50A immediately priorto and following, respectively, performance of operation "part" by meeting 
place 220B. Frame 3702 is a part of the execution state of agent 150Aand records the state of operation "part" 
as performed by meeting place 220B. Meeting place 2208 is property "responder" of frame 3702 and Is there- 
fore the responder of operation "part". Stack 3704 is property "stack" of frame 3702, which is also part of the 
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execution state of agent 150A, and is the current stack. 

At the top of stack 3704 is contact 3706. Contact 3706 identifies agent 1 SOB as the agent from which agent 
1 50A is to part. Engine 1 32B (Figure 1 6E), in carrying out performance of operation "part" on behalf of meeting 
place 2208, directs agent 150B to perfonm operation "parting". Agent 150B consumes as the sole argument 
a contact identifying agent 150A as the agent with whom agent 1 SOB is parting. Property "subjecT of the con- 
tact, which is usually a reference to agent 1 50A is voided by engine 1 32B prior to requesting operation "parting" 
so that agent 150B is not left with a reference to agent 150A after the meeting is terminated. 

In performing operation "parting", agent 150B produces no result The dynamic state of performance of 
operation "parting" is not part of the execution state of either agent 1 SOB (Figure 1 5E) or agent 150A, but is 
instead part of the execution state of an engine process. Any exception thrown by performance of operation 
"parting" is not experienced by. and therefore has no effect upon, either agent 150B or agent 150A. In per- 
forming operation "parting", agent 1 SOB is notified that agent 1 50A has tenminated the meeting between agents 
1 SOA and 1 SOB. If agent 1 SOB is a contacted agent, the item of property "contacts" of agent 1 SOA that is the 
contact referencing agent 150A is removed from property "contacts" of agent 150B. The access of operation 
"parting" is "system"; therefore, only engine 1 32B can request that agent 150B perform operation "parting". 

Figure 37B illustrates the state of agent 1 SOA immediately following perfbnmance of operation "parT by 
meeting place 220B. Stack 3704 is empty as operation "part" produces no result 

Tenminating a meeting between agents 1 SOA and 150B voids all references in agent 1 SOA to agent 150B 
and all objects owned by agent 160B. For example, in Figure 38, reference 150A-R1 that previously identified 
agent 150B and reference 150A-R2 that previously identified object 3604 are voided. Similarly, reference 
1 SOB-Rlthat previously referenced agent 1 SOA and reference 1 S0B-R2 that previously referenced object 3602 
are voided within agent 150B as well. Thus, agents 150A and 1S0B are no longer capable of exchanging in- 
formation. If agents 1 SOA and 1 SOB are contacted agents, a contact identifying agent 1 SOA is removed from 
property "contacts" of agent 1S0B. and a contact identifying agent 150B is removed from property "contacts" 
of agent 1S0A. 

Applicability of the Present Invention to Large, Widfr-Area Networks 

Thus far, a comnrujnications system is disclosed in which agent 1S0A (Figure 15A) transports itself, or a 
clone of itself, to meeting place 220B. which is occupied by agent 150B, by performance of operation "go" or 
operation "send", respectively. Agent 1S0A then requests perfbnmance of operation "meet" by meeting place 
220B to arrange a meeting between agent 1 SOA and agent 1 SOB. During the meeting, agents 1S0A and 1S0B 
are capable of exchanging information as described in greater detail below. 

While the foregoing discussion pertains to a very simple use of the present invention, much more general 
uses can be made of the present Inventton. Through application of the set of computer instructtons described 
herein and in Appendbc A, an agent Is capable of applying sophisticated and complex logic to detemilne to what 
places to transport itself and with which other agents and places to meet and exchange information. 

Additionally, the present invention is not limited to networks of two or three computer systenns, as described 
herein, and as prevk>usly stated, the present invention is not limited to homogenous networks. The set of conr>- 
puter instructions described herein and in Appendix A can be used to create and position places throughout a 
large area network such that agents can be created which travel throughout the large area network. As the 
disclosed instruction set can be implemented in heterogenous networks, the wide area network can include 
a wide variety of computer systems including large, mainframe computers; local area networks; and small per- 
sonal computere through which an agent in the wide area network can travel. 

Furthermore, while a meeting is defined as an interactkin between two agents, an agent is capable of par- 
ticipating in any number of meetings simultaneously and is therefore capable of interacting with a multitude 
of agents simultaneously, as long as those agents occupy the same meeting place occupied by the first- 
mentioned agent 

Interaction between Agents: Introductton to the Execution Model 

During a meeting between agent 1 SOA and agent 1 SOB, agent 1 SOA (Figure 1 5E) interacts with agent 1 SOB 
by issuing an instruction directing agent 1S0B to perform a feature. The following describes the mechanism 
by which performance of a feature is requested; this mechanism is discussed in greater detail below and in 
AppendbcA. 

An execution state is associated with each process. As discussed above in the Glossary of Terms, each 
method has a dynamic state during performance of the method. The execution state of a process includes one 
or more frames, each frame recording the dynamic state of a method which is part of the execution state of 
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the process. Within each frame is a stack on to which arguments are pushed prior to requesting operations, 
and from which results are popped after performance of operations. The stack of the current frame is the cur- 
rent stack. The current frame is the frame which contains the computer instruction whose execution is currently 
being carried out by an engine. 
5 Prior to requesting an operation, the requester pushes on to the current stack references to zero or more 

objects which are thereby supplied as arguments for the operatton. The requester then pushes on to the current 
stack a reference to the responder. The responder is the object which is directed by the requester to perform 
the requested operation. Finally, the requestor requests the execution of an identifier which identifies the re- 
quested operation. 

10 In carrying out performance of the requested operation, an engine pops an object from the top of the cur- 

rent stack, and the object is made the responder of the operation. A method implementing the operation is found 
within the classes of which the responder is a nnember and performed. In one embodiment, performance of 
the method (I) forms a new stack, (ii) pops the arguments of the operation from the current stack and pushes 
them on to the new stack, (iii) makes the new stack current, (Iv) pops arguments from the new current stack. 
15 (v) pushes a result, if one is produced by the operatton, on to the new current stack, and (vi) pops the result, 
if any, from the new current stack and pushes the result, if any, on to the previously current stack. The execution 
of operations, and features in general, is discussed in greater detail below and in Appendix A. 

The following example illustrates the mechanism by which operations are requested. As discussed above, 
during the course of a meeting, agent 150A interacts with agent 150B by directing agent 150B to perform an 
20 operation. Agent 150A grants agent 150B access to objects contained within agent 150A by supplying those 
objects as arguments to the operation requested. Agent 150B grants agent 1 50A access to an object contained 
within agent 150B by producing that object as a result of the requested operatton. 

Figures 39A-39F illustrate an example of agent 150A (Figure 15E, not shown in Figures 39A-39F) inter- 
acting with and passing infc»mation to agent 150B. 
25 Figure 39A shows empty stack 3902. Stack 3902 is the current stack of the execution state of agent 150A 

(not shown). While Figure 39A shows stack 3902 as being empty, such need not be the case. However, no 
objects on stack 3902 in Figure 39Aare affected by this example. String 3904 whose text is "this is a message" 
is pushed on to stack 3902 (Figure 39B). A reference to agent 150B is pushed on to stack 3902 (Figure 39C). 
Agent 150A next executes an identifier whose text is "store" and which references an operation "store". 
30 In execution of the identifier, an object, i.e. agent 150B. is popped from stack 3902 and the object is directed 
to perform operatton "store" (Figure 39D). In th is example, operation "store" is defined for a class of which agent 
1 SOB is a member and whose method Is represented by logic flow diagram 4000 (Figure 40). 

In perfomiing operation "store", agent 150B pops string 3904 from stack 3902 in step 4002 (Figure 40). 
Although agent 150B is described as performing operation "store", the frame (not shown) which records the 
35 dynamic state of agent 150B's performance of operation "store" Is part of the execution state of agent 150A 
(not shown). The charges allowance, i.e.. property "charges", of the permit of agent 150A is therefore debited 
for processing resulting from performance of operation "store" by agent 150B. Agent 150B is the object per- 
forming operatton "store" since (i) the execution state of agent 1 50A (not shown) identifies agent 1 SOB as the 
responder and since (ii) the method of operation "store" is provided by a class of which agent 1 SOB is a member 
40 and (iii) the internal state of agent 150B provides a context within which operation "store" is performed. 

Processing transfers from step 4002 to step 4004 in which string 3904-C, which is a copy of string 3904. 
is created, resulting in the state shown in Figure 39E. Strings 3904 and 3904-C are contained within frame 
3906 which is part of the execution state of agent 1 50A and which records the dynamic state of operation "store" 
as perfonmed by agent 1 SOB. Processing transfers from step 4004 to step 4006 (Figure 40) where agent 150B 
46 stores string 3904-C. Processing trarisfers from step 4006 to step 4008 in which agent 1S0B discards string 
3904, which was popped from stack 3902. Processing transfers from step 4008 to terminal step 4010 in which 
operation "store" completes successfully. Step 4008 results in the state represented by Figure 39F. Thus, agent 
ISOAhas successfully transferred information to agent 150B. 

In this manner, agent 150A interacts with agent 150B by agent 150A requesting agent 150B to perform 
50 an operatton, and agent 150A conveys to agent 150B objects as arguments to or results from operattons re- 
quested or performed, respecth^ely. While agent 150B is described as performing an operation at the request 
of agent 1S0A. It is reiterated here that performance of a feature by an object is. in actuality, performance of 
the feature by an engine in the context of that object defined by that object's internal state and class. The be- 
havior of a particular feature can vary depending on the internal state of the object performing the feature. 
55 where the internal state of the object is defined in part by the object's properties. 

Agent 1S0B can similarly transfer an object to agent 1S0A by pushing the object on to stack 3902. e.g.. 
after step 4008 and before terminal step 4010. The object is popped from stack 4010 as a result of operation 
"store" by agent 150A. Furthermore, since agent 1 SOB contains a reference to agent 1 50A, as discussed above 
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with respect to operation "meet", agent 150B is similarly capable of directing agent 150A to perform an oper- 
ation and of supplying to agent 150A objects as arguments to the operation. 

Portability of the Computer Instruction Set of the Present Invention 

5 

A number of aspects of the present invention permitprocessesagreatdealof mobility and versatility. First 
the computer Instruction set of the present invention is homogeneously implemented in a homogeneous or 
heterogenous network. Second, classes are objects of the computer instruction set so that classes can travel 
throughout the network with mobile processes. And third, the computer Instructran set is Interpreted. 

10 

Homogeneity of the Computer Instructfon Set 

As discussed above, an agent, which includes data and computer instructions, is capable of traveling from 
one computer system to another and of executing on whichever computer system the agent may be found. 
15 Furthermore, the network throughout which agents are capable of traveling can be either homogeneous or 
heterogeneous. In view of the mobility of agents, it is not always possible to determine exactly which computer 
system of the network executes each of the computer instructtons forming the procedural portion of an agent 
It is therefore important that each computer system of the network, throughout which agents can travel, sup- 
ports the same computer instruction set 

20 

Classes Represented as Objects in the Disclosed Computer Instruction Set 

An agent executing within a f iret computer system Is capable of creating new classes of objects which did 
not^reviously exist The agent can then travel to an engine which is executing within a second computer system 
25 and interpretation of the agent, involving processing of members of the newly created dass, continues within 
the second computer system. In such a case, the engine executing within the second computer system has 
never before encountered the newly created class or any members of that dass. Therefore, dasses are made 
objects of the disdosed instruction set so that dasses are capable of traveling with agents from one computer 
system to another. 

30 

Class Structure 



Several objects combine to define and represent a dass: a class object, an identifier, and a class definition. 
Class objects, identifiers and dass definitions are members of the respective dasses "Qass". "Identifier* and 

35 "Class Definition". Class objects, i.e., members of dass "Class", are objects which represent a set of objects 
whose features have the same Interface and Implementation. The set of objects are the "instances" of the dass. 
Class "Class" and dass objects are discussed in greater detail below and in Appendix A. 

Identif iere, i.e., membere of dass "Identifier*, are used within an interface object or an implementation 
object to reference a dass. It should be noted that identifiers reference other types of objects as well. Interface 

40 objects and implementation objects are discussed below in greater detail. A first identifier referencing a firet 
class within a first interface object or implementation object is distinct from identif iere referencing all other 
classes within the first interface object or implementation object However, a second interface object or Im- 
plementatton object can use an identifier equivalent to the firet identifier to reference a second dass. 

An interface object and an implementation object together define a number of features, i.e., operations 

45 and attributes. The distinctfon between an attribute, in which case an object Is directed to provide or alter a 
portion of the object's internal state, and an operation, in which case an object Is directed to perform a number 
of computer instructions, serves primarily to aid in conceptualczation of the present inventton. Conceptually, 
an attribute is a spedal case of an operation. For example, querying an attribute of an object directs the object 
to perform computer instructions which cause the object to provide information regarding the internal state of 

so the object 

It is reiterated here that perfomwince of a feature by an object is. in actuality, performance of the feature 
by an engine in the context of that object defined by that object's internal state and class. The behavior of a 
particular feature can vary depending on the internal state of the object performing the feature, where the in- 
ternal state of the object is defined in part by the object's properties. 
55 A single identifier can simultaneously identify two separate features, each feature defined by a different 

dass. For example, operation "add" is defined by class "Number" differently than by dass "Dictionary". In se- 
lecting an interface and implementation, the engine carrying out performance of a feature selects the feature 
def initton and associated method object appropriate for the dass of object performing the feature. In other 
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words, the feature def ihitton is retrieved from the classes of which the responder Is a member. Aconcrete dass 
defining a feature defines both the feature's interface and the feature's implementation. An abstract dass 
which defines a feature defines the feature's interface and can define the feature's implementation. 

The "interface" of a feature defines the arguments consumed in performance of the feature as welt as the 

5 result produced, if any. Additionally, the exceptbns which can be produced by a feature are defined by the 
feature's interface. The interfaces of the features defined by a dass are collectively represented and defined 
by an interface object, i.e.. a member of dass "interface", which is property "interface" of a dass definition 
object. Class "Interface" is discussed below in more detail. 

Afeature's implementation is defined by the feature's "method." Afeature's method defines actions to be 

10 taken, i.e. computer instructions to be executed, in performance of the feature. A method object, a member of 
class "Method", is generally a sequence of instructions whose execution constitutes performance of the fea- 
ture. The implementations of the features defined or inherited by a dass are collectively represented and de- 
fined by an implementation object, i.e., a member of dass "Implementation", which is property "implementa- 
tion" of a dass definition object. Class "Implementation' is discussed below in more detail. 

1$ Feature definitions are inherited from a dass's superclasses. In other words, if a feature is defined for a 

particular class, that feature is also defined for that dass's subdasses. However, a subdass is capable of re- 
defining the implementatton of the feature, superseding the implementation inherited from the superdass. 
However if the feature is "sealed" by a superdass of the subclass for which the feature is defined, the subdass 
cannot redefine the implementation inherited from the superdass. 

20 The features defined by a class are defined by the class's dass definition, a member of dass "Class Def- 
inition". The class itself is represented by a dass object a member of dass "Class". The dass is referenced 
by an identifier, a member of dass "Identifier*. 

A dass is created by first creating a dass definition, the structure of which is discussed in Appendix A. 
The dass definition is directed to perform operation "makeClasses" to create an associated dass object. The 

55 syntax and behavior of operation "makeClasses" is discussed in more detail in Appendix A. The particular form 
and structure of the formed class object is not essential so long as (i) the information contained within the dass 
definition object is preserved and (ii) citatwn 4108 (Figure 41A). interface object 4110, and implementation 
abject 411 2 can be derived from the dass object Condition (ii) is necessary for the encoding of a class object 
as described in Appendix B. 

30 The engine carrying out performance of operation "makeClasses" on behalf of dass definition 41 00 (Figure 

41A). in one embodiment, forms dass object 4102 (Figure 41B) by replicating in class object 4102 the prop- 
erties of dass definition 4100. After performance of operation "makeClasses", dass definition 4100 is discard- 
ed. The properties of dass definitton 4100 are discussed in greater detail below. As the properties of dass 
definltk)n 4100 are replicated in dass object 4102, dass object 4102 contains all of the information contained 

35 in dass definition object 41 00 and can derive the properties of dass definition object 4100. 

In another embodiment, processing efficlendes of compiled computer processes are realized by replicat- 
ing information in citatran 41 08. interface object 411 0 a nd implementation object 411 2 to form citation structure 
4108C (Figure 41C), interface structure 411 OC and implementatton structure 41 12C. respectively, within dass 
object 41 04. Computer processes whteh are fomied of computer instructions which are compiled, rather than 

40 interpreted, are generally more efficient i.e., perform a given task within a fewer number of CPU dock cydes, 
than computer processes whose instructions are interpreted. As discussed above, computer instructions are 
initially in human-intelligible source code. Before a computer instruction can be executed by a computer, the 
instruction must be translated into a computer-intelligible object code or machine code. As interpreted computer 
processes require such translatton for each computer instruction executed, and as compiled computer proc- 

46 esses do not require such translatton during executton of a compiled computer process, compiled computer 
processes can be subtstantially more efficient than interpreted computer processes. 

Citation structure 4108C. interface structure 4110C and implementation structure 4112C are objects 
which are analogous to citation 4108. interface object 4110 and implementation object 4112 and which are 
formed of compiled computer instructtons such the computer instructtons which collectively form the C++ pro- 

so gramming language. By replicating the strudures of citation 4108. interface object 4110, and implementation 
object 4112 (Figure 41A) in dass object 4104 (Figure 41C) as citatton structure 4108C. interface structure 
4110C, and implementation structure 4112C, respectively, information regarding the class represented by 
class object 4104 can be retrieved substantially more efficiently than by retrieving the information from citation 
4108, interface object 41 10 and implementatton object 41 12 of dass object 41 02 (Figure 41 B). The infonmation 

55 contained within citation structure 4108C (Figure 41C), interface structure 4110C. and implementatton struc- 
ture 4112C is substantially equivalent to the infonmation contained within the corresponding properties of dass 
deftnitton 4100 (Figure 41A). 

As the infomiation contained within a dass object is substantially equivalent to the informatton contained 
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Within the class definition from which the dass object is derived, discussion of the structure of a dass definition 
also descnbes the nature of the information contained within a dass object 

Class Definition Objects 

The features defined by a dass are defined In the dass definition object which defines the dass. The struo- 

-h'^.I'^T. ''^^"'^ ^^^^ -^100 *"dudes properties 

H H ^""^ implementation". Citatton 4108 is property "citation- of dass definition object 4100 

and Identiftes the dass defined by dass definition object 4100 and further identifies the authority, title and 
edition of the dass. The structure of a citation is discussed in greater detail below and in Appendbc A 

nterface object 4110 and implementation object 4112 are. respectively, properties "interface" and "imple- 
mentation of dass definition object4100. Interface object 4110 defines the interfaces of the features defined 
by dass definrtion object 4100. and implementation object 4112 defines the implementations of the features 
defined by class definition object 4100. "'aiuioa 

Interface objects 

The structure of interface object4110 is shown In Figure 42. The properties of Interface object4110 indude 
properties "isAbstracT, "dassFeatures", "sealedClassFeatures". "instanceFeatures". "sealedlnstanceFea- 
20 tures", "vocabulary" and "superdasses". 

Boolean 4208 is property "IsAbstracT of interface object 4110. If boolean 4208 is "true", the dass. whose 
interface is Interface object 4110. Is abstract. The dass is concrete otherwise. 

Lexicon 4210 is property "dassFeatures" of Interface object 4110. Lexicon 4210 is a lexicon of the defi- 
nitions of the dass features" of the dass. The dass features of a dass are the features for which the dass 
Itself, i.e. the dass represented by dass definition object 4100 {Figure 41A). Is the responder. The keys of 
lexicon 4210 (Figure 42). e.g.. identifier 421 OK. are identifiers which reference the dass features. The values 
of lexicon 4210, e.g.. feature definition 4210V. are feature definitions defining the dass features. Feature def- 
initions are discussed below in more detail. 

Set 4212 is property "sealedClassFeatures" of interface object 4110. Set 4212 Is a set of identifiers e g 
Identifier 42121. which reference the dass features which are sealed. Sealed features are features that sub^ 
classes are prevented from adapting. If a feature is not sealed, a subdass of the class represented by dass 
definition object 4100 (Figure 41A) can adapt the feature by redefining the feature's implementation 

Lexicon 4214 (Figure 42) is property "instanceFeatures" of interface object4110. Lexicon 4214 Is a lexicon 
of the definitions of the "Instance features" of the dass. The Instance features of a class are features for which 
members of the dass are the responder. The keys of lexicon 4214 (Figure 42) (no key or value of lexicon 4214 
is shown) are identifiers referendng the instance features, and the values of lexicon 4214 are feature defini- 
tions defining the instance features. 

Set 4216 is property "sealed! nstanceFeatures" of interface object 4110. Set 4216 is a set of kJentlfiers 
(not shown) which reference the instance features which are sealed. 

Lexicon 4218 is property Vocabulary" of interface object4110. Lexicon 4218 associates identifiers of user- 
defined classes which are referenced In Interface object 4110 with citations of those dasses. The keys of lex- 
icon 4218 are identifiers, e.g.. kientifier 4218K. and the values of lexicon 4218 are corresponding dtations 
e.g.. citation 4218V. Citattona are discussed In greater detail below and In Appendbc A. Property "vocabulary" 
of interface object 4110. i.e.. lexicon 4218, is "the vocabulary" of interface object 4110 and of the dass defined 
« by dass definition object 4100 (Figure 41 A). 

Ust 4220 (Figure 42) Is property "superclasses" of interface object 4110. List 4220 Is a list of identifiers, 
e.g.. Identifier 42201. which reference classes. The dasses referenced by identifiers of list 4220 are Immediate 
interface superdasses of the dass defined by dass def initton object 4100 (Figure 41A) . All but the last item 
of list 4220 (Figure 42) must identify mix-in dasses, and the last item of list 4220 must identify a flavor The 
so importance of the last Item of list 4220 identifying a flavor is discussed below in more detail In conjunction 
with the selection of a method object in performing a feature and In conjunction with object Initialization. 



25 



30 



35 



40 



55 



Feature Definitions 



Afeatune definitran, i.e.. a member of dass "Feature", Is an object which defines the interface of a particular 
feature. The properties of feature definition 4210V (Figure 43) indude properties "exceptions" and "isPublic". 
Class "Feature" is abstract; therefore, feature definition 421 OV Is a member, not an instance, of dass "Feature" 
and is either an operation definition or an attribute definition, both ofwhteh are described below and in Appendix 
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A. Set 4302 is property "exceptions" of feature definition 4210V. Set 4302 is a set of identifiers, e.g., identifier 
43021, which each reference a class of which exceptions thrown by the feature defined are members. When 
the feature defined by feature definition 4210V throws an exception, the exception is verified to be a member 
of one of the classes referenced by an identifier of set 4302. If the exception is not a member of a class ref- 

5 erenced by an identifier of set 4302. a member of class "Unexpected Exception" is thrown in place of the ex- 
ception. Otherwise, the exception is thrown. 

Boolean 4304 is property "isPublic" of feature definition 4210V. Boolean 4304 indicates whether the fea- 
ture defined by feature definition 4210V is a public feature or a private feature, i.e. whether the access of the 
feature defined is "public" or "private". Each feature has an associated "access" which determines which ob- 

10 jects and under what circumstances each feature can be properly requested. The access of each feature of 
this invention is disclosed in Appendices A and B. 

If boolean 4304 is "true", the feature is public, A feature whose access is public can be requested by any 
object If boolean 4304 is "false", the feature is private. Afeature whose access is private can only be requested 
by the responder. I.e.. an object can only request the feature of itself. System features, i.e.. features whose 

13 access is "system", are all predefined and therefore are not defined by feature definitions. Predefined features 
are implemented within an engine and therefore are not represented by objects such as feature definitions. 
One implementatton of an engine of one embodinnent of the present invention, which implements the disclosed 
predefined features. Is disclosed in the software of Appendix G which is incorporated herein in its entirety by 
reference. 

20 

Attribute Definitions 

A feature definition that defines an attribute is an attributa definition, i.e., a member of class "Attribute". 
Therefore, dass "Attribute" is a subclass of dass "Feature". As an attribute definition is a feature definition. 
25 an attribute definition inherits the properties defined or inherited by class "Feature" as described above. In 
addition, attribute definition 4400 (Figure 44) indudes properties "constrainr and "isSet". 

Constraint 4402 is property "constrainr of attribute definition 4400. Constraint 4402 constrains objects 
representing the attribute defined by attribute definition 4400. As d iscussed below in greater detail, a constraint 
places restrictions on an object and can restrict (i) the dass of which the object is a member, (ii) whether the 
30 object must be an instance of the dass, (iii) whether the object can be a nil and (iv) how the object is passed 
between a feature's requester and responder. 

Boolean 4404 is property "isSer of attribute definition 4400. Boolean 4404 indicates whether the attribute 
defined by attribute definition 4400 can be set as well as queried. If boolean 4404 is "true", attribute definition 
4400 defines an attribute which can be set Otherwise, the attribute defined by attribute definition 4400 can 
35 only be queried. 

Operation Definitions 

As discussed above, a feature is either an attribute or an operation. Therefore, a second subclass of dass 
40 "Feature" is class "Operation". An operation definition, i.e., a member of dass "Operation", defines the inter- 
face of an operation. 

Figure 45 shows the structure of operation definition 4500. As an operation definition is a feature definition, 
operation definition 4500 indudes the properties defined or inherited by dass "Feature" as described above. 
In addition, operation definition includes properties "arguments" and "result". 

« List 4502 is property "arguments" of operation definition 4500. Property "arguments" of an operation def- 

inition is optional, i.e., property "arguments" of an operation definition can be a nil rather than a list If property 
"arguments" is a nil, the operation defined by operation definition 4500 consumes a variable number of argu- 
ments. The performance of an operation whose arguments are variable in number is described in Appendix 
A. Convereely, if property "arguments" is list 4502. the number of arguments consumed by the operation de- 

M fined by operatton definition 4500 consumes a fixed number of arguntents, the number being equal to the 
length of list 4502. If property "arguments" is an empty list the operation consumes no arguments. The items 
of list 4502. e.g., constraint 45021, are constraints which constrain the arguments of the operation defined by 
operation definition 4500. As discussed below with respect to Figure 46, a constraint constrains an object's 
class and passage. 

w Constraint 4504 is property "result" of operation definition 4500. Constraint 4504 constrains the result of 

the operation defined by operation definition 4500. Property "resuir of an operation definition is also optional. 
If property "resuir is a nil rather than constraint 4504, then the operation defined by operation definition 4500 
produces no result 
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Constraints 

As discussed above, a constraint restricts the class and passage of an object. The structure of constraint 
4402 is shown in Figure 46. The properties of constraint 4402 indude properties "dassld", "ofQass" "isln- 
5 stance". "isOptional". and "passage". 

Properties "ofClass" and "dassld" are alternative ways for specifying the dass of which the constrained 
object nnust be a member. Class object 4602 is property "ofClass" of constraint 4402. Class object 4602 rep^ 
resents the dass of which an object upon which constraint 4402 is imposed must be a member. Property "of- 
Class" is optional and. therefore, can be a nil. If property "ofClass" is nil, the dass of which the object must 
10 be a member is referenced by identifier 4610 which is property "dassld" of constraint 4402. 

Property "ofClass" is a dass object and therefore can only be a dass which exists at the time constraint 
4402 is created. However, requiring that a property of a constraint is a class which exists prevents users of 
the present invention from defining multiple interdependent dassea. For example, a constraint in a feature def- 
inition of a first dass can refer to a second dass and a second constraint in a second feature definition in the 
15 second dass can refer to the first dass. Providing property "dassld" of constraint 4402 as an alternative to 
property "ofClass" enables usere to define multiple interdependent dasses simultaneously. 

Boolean 4604 is property "islnstance" of constraint 4402. Boolean 4604 Indicates whether an object upon 
which constraint 4402 is imposed must be an instance of the dass represented by dass object 4602. If boolean 
4604 is "true", the constrained object must be an instance of the dass. Otherwise, the constrained object's 
20 membership in the dass is sufficient to satisfy constraint 4402. 

Brolean 4606 is property "isOptional" of constraint 4402. Boolean 4606 indicates whether a nil object sat- 
isfies constraint 4402, properties "ofClass" and "dassld" notwithstanding. If boolean 4606 is "true", a nil object 
satisfies constraint 4402. As illustrated in numerous examples herein, a nil object can be placed on a stack in 
lieu of an omitted optional argument or result of a feature. 
25 Identifier 4610 is property "passage" of constraint 4402. Identifier 46 10 indicates in what manner an object 
on which constraint 4402 is imposed is passed as a parameter, i.e., as an argument or result Identifier 4610 
has four possible values: "byRer, "byUnprotectedRer, "byProtectedReT and "byCopy". Setting identifier 4610 
to a value other than one of these four throws an exception that is a member of dass "Passage Invalid". 

In passing a reference to an argument between the requestor of a feature and the responder of the feature, 
30 an engine takes a source reference to the argument from the requestor and provkles a destination reference 
to the responder. In passing a reference to a result the source reference is taken from the responder and a 
destination reference is provided to the requestor. 

If the parameter is passed "byReT, the source reference and the destination reference are the same. If 
the parameter is passed "byUnprotectedRer. an exception of dass "Reference Protected" is thrown if the 
35 source reference is a protected reference; otherwise, the destination reference is the source reference. If the 
parameter is passed "byProtectedReT. the destination reference is a protected reference to the object refer- 
enced by the source reference. If the parameter is passed "byCopy". the destination reference is an unprotected 
reference to a copy of the object referenced by the source reference. Passage of parameters is discussed fur- 
ther in AppendbcA. 

^ Thus, constraint 4402 (Figure 44) restricts the class and passage of an object 
Implenrontation Object 

As discussed above, implementation object 4112 (Figure 41A) defines the dass implementation of the 
45 class defined by class def inltton object 4100. A dass implementation defines the following: (i) zero or more 
properties of the membera of the dass defined; (10 the respective implementations of the various dass features 
and (iii) instance features defined by a dass; (iv) methods for setting attributes defined for the dass; (v) meth- 
ods for converting objects from the dass defined to a second dass; (vi) methods for converting objects from 
a second dass to the dass defined; (vii) definitions of identifiers used to define dasses; and (viii) the impla- 
50 mentation superdasses of the dass defined. 

Ust 4702 (Figure 47) is property "properties" of implementation object 4112. List 4702 defines the prop- 
erties that implementation object 4112 implements. The items of lexicon 4702, e.g.. identifier 47021. are iden- 
tif iere of the properties defined by implementation object 4702. 

Lexicon 4704 (Figure 47) is property "classMethods" of implementation object 4 11 2. Lexicon 4704 provides 
55 methods for the dass features of the dass represented by dass definition object 41 00 (Figure 41 A). The keys 
of lexicon 4704, e.g., kJentifier4704K (Figure 47), are identifiers of the dass features, and the values of lexicon 
4704. e.g., method object 4704V. are method objects which define the implementation of the dass features. 

A method object i.e., a member of class "Method", is an object which defines the method of a feature. 
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The method of a feature is the particular series of steps taken by an engine, and therefore the computer system 
within which the engine is executing, in carrying out performance of the feature. 

A method is defined in ternns of the disclosed instruction set as the instruction set is amended by any user- 
defined classes or features. Method objects are discussed in greater detail below and in Appendix A. 
5 Lexicon 4706 is property "instanceMelhods" of implementation object 411 2. Lexicon 4706 associates iden- 

tifiers of instance features with corresponding method objects, which in turn define the implementation of the 
instance features. The structure of lexicon 4706 is similar to the structure of lexicon 4704 and that discussion 
is Incorporated herein by reference. 

Lexicon 4707 is property "setMethods" of implementation object4112. Lexicon 4707 associates identifiers. 

10 which identify respective attributes, with method objects. Each of the method objects of lexicon 4707 imple- 
ments the attribute of the corresponding identifier when executed in the presence of a "set" modifier. In other 
words, each method object of lexicon 4707 defines the implementation of the setting of a corresponding at- 
tribute. The execution of an attribute in the presence of a "set" modifier is discussed in Appendix A. 

Lexicon 4708 is property "fromMethods" of implementation object 4112. Lexicon 4708 associates identi- 

15 f iers with method objects. Each identifier references a class and is associated with a method object which pro- 
vides the implementation of the conversion from the referenced class to the class defined by class definition 
object 4100 (Figure 41A). i.e.. the dass whose implementation is implementation object 4112 (Figure 47). 

Lexicon 4710 is property "toMethods" of implementation object 4112. Lexicon 4710 associates identifiers 
with method objects. Each identifier references a dass and is associated with a method object which provides 

20 the implementation of the convereion to the referenced dass from the dass defined by dass definition object 
4100 (Figure 41 A), i.e., the dass whose implementation is implementation object 4112 (Figure 47). The struc- 
ture of lexicons 4707. 4708 and 4710 is similar to the structure of lexicon 4704 and that discussion is incor- 
porated herein by reference. 

Lexicon 4712 is property "vocabulary" of implementation object 4112. Lexicon 4712 defines the identifiers 

25 used by implementation object 4112 to identify dasses. The keys of lexicon 4712. e.g.. identifier 4712K, are 
identifiers used within implementation object 41 1 2 to identify specific user-defined dasses. The values of lex- 
icon 4712. e.g.. citation 4712V, are conresponding citations which identify the class identified by the associated 
identifier. Lexicon 4712 provides a translation between an identifier used to identify a user-defined class within 
implementation object 4112 and a citation used to identify the dass throughout the network. Citations are dis- 

30 cussed in greater detail betow and in Appendix A. 

List 4714 is property "superclasses" of implementation object 4112. The items of list 4714, e.g.. identifier 
47141, are identifiers which identify the implementation superdasses of the dass defined by class definition 
4100 (Figure 41 A). List 4714 (Figure 47). i.e. property "superclasses" of implenrwntation object 4112, can con- 
tain identifiers of classes which are not Hems of list 4220, i.e. property "superclasses" of interface object 4110. 

35 For example, a first class nnay benefit from the ability to use features of a second class in Implementing fea- 
tures of the first dass. However, in designing such a dass. it is not always preferred that the features of the 
second dass are themselves inherited by the first dass. In such cases, the second class is made an imple- 
mentation superdass but not an interface superdass of the first dass. 

Thus, implementation object 4112 defines, for the dass defined by dass definition object 4100 (Figure 

40 41 A), (a) properties of the members of the dass defined, (b) the dass and instance feature methods, (c) meth- 
ods for setting attributes, (d) methods for conversion to and from the class defined, (e) identifiere used to iden- 
tify dasses. and (f) implementation superdasses. 

Method Objects 

4S 

As discussed above, a method object defines the computer instructions executed in performance of a fea- 
ture or a conversion. Figure 48 shows the structure of method object 4800. Properties of method object 4800 
include properties "procedure" and "variables". Procedure 4802 is property "procedure" of method object 4800. 
Performance of procedure 4802 constitutes performance of the feature or a converefon implemented by meth- 
50 od object 4800. Procedures are discussed In more detail below. 

List 4804 is property "variables" of method object 4800. List 4804 defines the variables that are used by 
procedure 4802. The items of list 4804. e.g., identifier 48041, are identifiers which reference the variables de- 
fined for method object 4800. Associated objects which represent the values of the variables of a method are 
stored in a list as property "variables" of a user-defined frame during performance of the method. Frames are 
55 discussed in greater detail below and in Appendix A. 
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"Integer" is defined to provide an operation "randonr^ize" to generate random numbers. The former dass "In- 
teger" is called the first class "Integer*. Property "citation" of the second dass "Integer* is a second citation. 
Suppose further that there are no other differences between the first dass "Integer" and the second dass "In- 
teger" and that any feature requested of a member of the first dass "Integer* is satisfied by a member of the 
5 second dass "Integer". Thus, the features which are designed in reliance of integers comporting with the de- 
scription of the first class "Integer", function properly given integers of the second dass "Integer". The second 
class "Integer" is therefore backward-compatible with the first dass "Integer*. Conversely, the first dass "In- 
teger" is forward-compatible with the second dass "Integer*. 

Property "title" of both the first and the second citations Is equal and references either dass "Integer*. How^ 
10 ever, the major and minor editions of the first and second citations reflect the forward- and backward-compa- 
tibility relation between the first and second classes "Integer". Permitting backward- and forward-compatible 
objects to co-exist within the network pennits objects created by earlier versions of the set of computer in- 
structions described herein to travel to and operate within engines implementing a later version of the set of 
computer instructions described herein, it is dear from the foregoing that a dass is both forward- and back- 
is ward-compatible with itself. While the illustrative example above demonstrates forward- and backward-com- 
patibility in the context of a predefined class, user-defined classes are typically changed more frequently than 
predefined classes. Therefore, providing forforward- and backward-compatibility among dasses is particularly 
important in the context of user-defined dasses. 

Thus, dasses are made part of the disdosed instructk)n set and are therefore portable and can travel with 
20 an agent from a first computer system to a second computer system. 

Interpreted Instruction Set 

As discussed above, three aspects of the present invention make computer processes particulariy mobile 

25 and general. The first is that the computer instruction set of the present invention is implemented homogene- 
ously in a honrwgeneous or heterogeneous network. Secondly, dasses are objects of the disdosed computer 
instruction set so that the instruction set is both extensible and nrobile. That is. dasses. which are not defined 
on remote computer systems, are transported with mobile confiputer processes to such remote computer sys- 
tems. The following discussion concerns the third aspect making the computer instruction set particularly gen- 

30 eral and mobile; the computer instructions of the disdosed computer Instruction set are interpreted. 

Most computer processes are first written in a human-readable source code which is then compiled into 
object code and linked into machine code, which is entirely unintelligible to human beings. The primary advan- 
tage of translating the source code into machine code is that the translation need occur only once as the ma- 
chine code can be executed by a computer system's CPU any number of times without recompilation of the 

35 source code. However, two computer systems of a heterogeneous network can have incompatible CPUs which 
do not both execute identical machine code Instructions. It Is therefore preferred that agents, traveling from 
a first computer system to a second computer system, be represented in a standardized instructton set that is 
not specific to either the firet or the second computer system. 

Since the advantages of one-time compilatton of source code are eliminated by the heterogeneity of the 

40 network, the disdosed computer instructron set is interpreted. The term "interpreted" is used herein as it is 
understood in the art; a computer instruction in a series of computer instructions is read, translated into ma- 
chine code, and executed by an engine before the next computer instruction in the series is read. 

Interpreting, rather than compiling, instructions of the disdosed instruction set provides greater generality. 
A f irat agent can travel from a first computer system to a second computer system and meet with a second 

46 agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perform. 

The following discusses the interpretation of the disdosed computer instructions. The discussion focuses 
on procedures and executk)n of items of procedures, the items being tndn^idual computer instructions. 

so Execution of a Procedure 

A procedure is performed by issuing an instruction requesting that the procedure perform operatton "do". 
Other operations which cause performance of a procedure are discussed below and in Appendix A. Perfor- 
mance of operatton "do" as defined for dass "Procedure" is shown by logic flow diagram 5200 (Figure 52A) 
55 and is represented by a predefined frame 5250 (Figure 52B). Predefined frame 5250 includes properties "pos- 
ition" and "procedure", which are, respectively, integer 5252 and procedure 4802. Predefined frames are dis- 
cussed in greater detail in Appendix B. Predefined frame 5250 records the dynamic state of operation "do" as 
performed by procedure 4802 (Figure 49). 
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In step 5202 (Figure 52A). integer 5252 is set to a value of one. Integer 5252 identifies the position, within 
procedure 4802. of the item whose execution was most recently begun. Processing transfers from step 5202 
(Figure 52A) to end of procedure test step 5204 In which integer 5252 (Figure 52B) is compared to the length 
of procedure 4802. If integer 5252 is less than or equal to the length of procedure 4802. processing transfers 
from end of procedure test step 5204 (Figure 52A) to step 5208. In step 5208. the item, whose position within 
procedure 4802 (Figure 52B) is integer 5252 is perfonmed. The performance of an executed object is discussed 
below in more detail and in Appendix A. 

Once an item of procedure 4802 is perfbmied, processing transfers from step 5208 (Figure 52A) to ex- 
ception test step 5210. In exception test step 5210. the engine interpreting procedure 4802 (Figure 52B) de- 
termines whether performance of the item succeeded or threw an exception. If an exception is thrown, proc- 
essing transfers from exception test step 5210 (Figure 52A) to terminal step 6212 in which operation "do" fails 
and the performance of procedure 4802 (Figure 52B) completes. 

If no exception is thrown by performance of the item at the position within procedure 4802 indicated by 
integer 5252 in step 5208 (Figure 52A). processing transfers from exception test step 5210 to step 5214 in 
which integer 5252 (Figure 52B) is incremented. Processing transfers from step 5214 (Figure 52A) to end of 
procedure test step 5204 in which property "position" of predefined frame 5250 (Figure 52B), i.e., integer 5252. 
is compared to the length of responding procedure 4802 as described above. 

If integer 5252 (Figure 52B) is greater than the length of procedure 4802, processing transfera from end 
of procedure test step 5204 (Figure 52A) to terminal step 5216 in which operation "do" completes successfully. 

Thus, performance of operation "do" by procedure 4802 (Figures 49 and 52B) results in the execution of 
each of the items of procedure 4802 in the order described above. 

Execution Model 

As discussed above, the primary function of an engine, e.g.. engine 1 32B (Figure 1 5A). is the performance 
of procedures. Le.. the execution of the items of procedures. The execution nriodel of the disclosed embodiment 
of the present Invention is the process by which items of procedures are executed. Discussion of the execution 
model of the disclosed embodiment is divided into six sections. First, the structure and organization of frames 
is discussed. Frames are objects which record the dynamic state of a method implementing a feature or a con- 
version. Second, the execution of identifiers is discussed. The execution of an identifier which references a 
feature causes the feature referenced to be performed. Third, the process by which a method object imple- 
menting a feature or a conversion is selected from the class hierarchy is discussed. The structure of class 
objects, from which a method object is retrieved, is described above. Fourth, the escalation of a feature is dis- 
cussed. Fifth, the execution of modifiers is discussed. And sixth, the execution of selectors is discussed. 

Frames 

A frame is an object which records the dynamic state of a method implementing a feature or a converelon 
during the feature's or convereion's execution. The execution state of a process, i.e., an agent or a place, is 
recorded in one or more frames. For example, the execution state of process 5300 (Figure 63) is shown. When 
a process is created, the process is asked to perform operation "live". Created within process 5300 is a property 
"frames" which is stack 5302 which in turn represents the execution thread of process 5300. Stack 5302 con- 
tains the frames which collectively form the execution state of process 5300. When process 5300 is first asked 
to perform operation "live", the sole item on stack 5302 is user-defined frame 5304 which records the dynamic 
state of operation "live". 

Since predefined classes "Process". "Agenr and "Place" are abstract, processes of the disclosed embodi- 
ment of the present Invention are instances of user defined classes. Predefined abstract classes "Process". 
"Agenr and "Place" do not define an implementation for operation "live". Therefore, frame 5304 recording the 
dynamic state of the method of operation "live" is necessarily a user-defined frame. A user-defined frame is 
a frame which records the dynamic state of an operation with a user-defined implementation during execution 
of the operation. The structure of user-defined frame 5304 is shown in Figure 54. 

The properties of user-defined frame 5304 (Figure 54) include properties "class", "responder". "proce- 
dure", "position", "stack" and Variables". Class object 5402 is property "class" of user-defined frame 5304. 
which is a property inherited from superclass "Object". Class object 5402 represents the dass of which user- 
defined frame 5304 ts an instance and therefore represents dass "User-defined Frame" or a subdass thereof. 

Object 5404 is property "responder of user-defined frame 5304. Object 5404 is the responder of the fea- 
ture or conversion whose dynamic state user-defined frame 5304 records. In the context of Figure 53. object 
5404 is process 5300 as process 5300 is the responder of operation "live". 
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Procedure 6406 (Figure 54) is property "procedure" of user-def ined frame 5304, which is a property in- 
herited from superclass "Procedure Frame". Procedure 5406 is property "procedure" of the method object 
whose dynamic state user-defined frame 5304 records. For example, if user-defined frame 5304 records the 
dynamic state of method object 4800 (Figure 48), procedures 4802 and 5406 are the same procedure. 

5 Integer 5408 is property "position" of user-defined frame 5304 inherited from superclass "Procedure 

Frame". Integer 5408 identifies the position within procedure 5406 of the item of procedure 5406 which is cur- 
rently being executed. For example, if the second item of procedure 5406 is the item of procedure 5406 whose 
execution has begun and has not yet finished, the value of integer 5408 is two. 

User-defined frame 5304 includes two additional properties, namely, properties "stack" and "variables". 

10 Stack 5410 is property "stack" of user-defined frame 5304 and is the stack of user-defined frame 5304. At the 
beginning of execution of procedure 5406, stack 5410 contains the arguments consumed by performance of 
the feature or converaion whose dynamic state is recorded by user-defined frame 5304. After execution of pro- 
cedure 5406, stack 6410 contains the result, if any, produced by performance of the feature or converaion. 
List 5412 is property "variables" of user-defined frame 5304. The items of list 5412. e.g. object 54121, are 

IS the variables of the frame. Variables record the dynamic state of user-defined f ran>e 5304 as procedure 5406 
is performed. Variables which are items of list 5412 (Figure 54) are referenced by like- positioned items of prop- 
erty "variables" of the method object whose dynamic state is recorded by user-defined frame 5304. For ex- 
ample, if user-defined frame 5304 records the dynamic state of method object4800 (Figure 48). identifier 48041 
which is at position one within list 4804 references object 54121 (Figure 54) which is at position one within list 

20 5412. 

Thus, user-defined frame 5304 records the dynamic state of a user-defined feature or converaion by re- 
cording (i) ^he responder of the feature or converaion. (ii) the procedure implementing the feature or converaion. 
(ill) the position within the procedure of the cun-ently executing instruction, (iv) the stack containing the argu- 
ments or result of the feature or converaion and (v) the variables which record the dynamic state of user-defined 
25 frame 5304. 

Execution of Executed Objects 

As discussed above, the performance of a procedure is the sequential execution of the items of the pro- 
30 cedure. In general, the execution of an executed object, i.e., an object which inherits from mix-in dass "Exe- 
cuted", results in a reference to the object being pushed on to the stack, e.g., stack 5410, of the frame repre- 
senting the execution state of the procedure. However, the execution of identif iera. modifiers and selectora 
are excepttons to this general rule. 

35 Identlflere 

Unless executed in the presence of a modifier indicating otherwise, an executed identifier is presumed 
to reference a feature and therefore invokes an operation or queries an attribute. Execution of an identifier 
within a f irat procedure causes the feature referenced by the identifier to be performed, thereby causing the 

40 performance of a second procedure. The second procedure is the procedure of the method object which inv 
plements the operatton or attribute referenced by the identifier. The execution of an identif ier which references 
a feature is shown by logic flow diagram 5500 (Figure 55). 

Logic flow diagram 5500 is discussed in the context of Figures 56A-56C. Stack 5302 (Figure 56A) is the 
execution thread, i.e.. property "frames", of process 5300. User-defined frame 5304 is the current frame. The 

46 current frame is the frame containing the procedure, i.e.. procedure 5406. whose items are currently being 
executed by an engine. In other words, the next executed object, which an engine executes in the interpretation 
of process 5300. is retrieved from the procedure of user-defined frame 5304. 

Procedure 5406 is property "procedure" of user-defined frame 5304. Integer 5408 is property "position" 
of user-defined frame 5304 and indicates the position within procedure 5406 of the item whose execution was 

so most recently begun by the engine processing process 5300. 

The execution of an identifier occure when the item of procedure 5406 at the position indicated by integer 
5408 is an identifier. In this example, the identifier references an operation. The operation referenced by the 
identifier is sometimes called "the subject operation" in the context of Figures 56A-56C and 55. The execution 
of the identifier is shown by logic flow diagram 5500 (Figure 55). 

55 The requester's stack, i.e. stack 541 0. is produced by querying attribute "stack" of user-defined frame 5304 

in step 5502. Since performance of procedure 5405 (Figure 56A) of user-defined frame 5304 is requesting 
execution of the identifier at the position within procedure 5406 indicated by integer 5408, property "responder" 
of user-defined frame 5304. which is the current frame, is the requester of the operation referenced by the 

57 



BNSDOCID: <EP 0634719A2_L> 



EP 0 634 719 A2 



identifier. In the context of Figure 56A, the responder is process 5300. Stack 541 0 is therefore the "requester's 
stack". 

Processing transfers from step 5502 (Figure 55) to a stack empty test step 5504. At the time the identifier 
is executed, the object at the top of stack 5410 is the responder of the subject operation. In stack empty test 
5 step 5504. the engine interpreting process 5300 determines whether stack 541 0 is empty. If stack 541 0 is de- 
termined to be empty, processing transfers from stack empty test step 6504 to terminal step 5506 in which an 
exception of the dass "Responder Missing" is thrown and the subject operation fails. Otherwise, if stack 5410 
is not empty, processing transfers from stack empty test to step 5508 in which the object (not shown) at the 
top of stack 5410 is popped from stack 5410. The object popped from stack 5410 is the Intended responder 

10 of the subject operation of the executing Wentif ier and is sometimes referred to as "the responding object" in 
the context of Figures 56A-56C and 55. 

It should be noted that the subject operatton is user-defined and therefore represented by a user-defined 
frame. Features which are predefined are represented directly in an engine. In other words, the instructions 
which form a predefined operation are included In the instructions which form the computer process that is an 

15 engine. If the executed identifier references a predefined operation, the instructions which define the operatton 
within the engine are located and performed. One implementation of an engine of one embodiment of the pres- 
ent invention, including instructions which define the predefined operations described herein and in Appendix 
A, is disclosed in the software of Appendix G which is incorporated herein in its entirety by reference. 

Processing transfere from 5508 to step 5510. In step 5510. the operatton definition defining the subject 

20 operation is retrieved. The selectton of the operation definition and the associated method object is discussed 
below In detail. Processing transfers from step 5510 ^o access test step 5512. In access test step 5512. the 
access of the subject operatton is verified. Property "isP'ublic". e.g.. boolean 4404 (Figure 44). is retrieved from 
the operation definition. If the access of the subject operatton is not "public", i.e., if property "isPublfc" is "false", 
and the responding object is not property "responder" (not shown) of user-defined frame 5304, processing 

25 transfers from access test step 5512 to terminal step 5514. 

In tenninal step 5514, an exceptton of class "Feature Unavailable" is thrown and the subject operatton fails. 
Otherwise. If property "isPublic" is "true" or the responding object is property "responder" of user-defined 
frame 5304. the access of the subject operatton is acceptable and processing transfers from access test step 
551 2 to number of arguments test step 551 6. 

30 In number of arguments test step 5516. property "arguments" of the operatton definitton is produced by 

querying attribute "arguments" of the operatton definition. The number of items in the list of property "argu- 
ments" is compared to the number of objects on stack 5410. If property "arguments" defines a number of ar- 
guments that fs greater than the number of objects present on stack 5410. processing transfere from number 
of arguments test step 5516 to terminal step 551 8. In terminal step 5518. an exception of class "Argument Mlss- 

3S ing" is thrown, causing the subject operation to fail. 

It should be noted that any exception thrown by executton of the identifier which references the subject 
operation, e.g., in either terminal step 5506 or terminal step 5514, causes the subject operation to fail, throwing 
the same exceptton. 

If stack 5410 contains at least as many objects as there are arguments as indicated by property "argu- 
te ments" of the operation definition retrieved in step 551 0, processing transfere from number of arguments test 
step 5516 to classes of arguments test step 5520. In classes of arguments test step 5520, the engine inter- 
preting process 5300 determines whether each object on stack 5410 in the positton of an argument satisfies 
the corresponding constraint within the list that is property "arguments" of the operation definition retrieved 
in step 551 0. For example, constraint 45021 of list 4502 (Figure 45), wh toh is property "arguments" of operation 
45 definitton 4500, corresponds to the object at the top of stack 541 0. The structure of a constraint is discussed 
in greater detail above and in Appendbc A. 

As discussed above in greater detail, a constraint restricts an object by specifying (I) a dass of which the 
object must be a member, (li) whether the object must also be an instance of the dass specified, and (ill) wheth- 
er a nil satisfies the constraint irrespective of the dass specified. Each object on stack 5410 which corresponds 
so to a constraint is examined to determine whether the object satisf ies the constraint in classes of arguments 
test step 5520, If any of the objects on stack 5410 does not satisfy the corresponding constraint of property 
"arguments" of the operation definition, processing transfers from dasses of arguments test step 5520 to ter- 
minal step 5522 in which an exceptton of class "Argument Invalid" is thrown. 

Convereely. if each of the objects on stack 541 0 satisfies the corresponding constraint, processing trans- 
55 fers from dass of arguments test step 5520 to step 5524. In step 5624. the method object defining the imple- 
mentation of the subject operation in the context of the responding object is selected. The method object is 
selected from the classes of which the responding object is a member as discussed in greater detail below. 
Processing transfers from step 5524 to step 5526 in which a new user-defined frame 5602 (Figure 56B) 
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is created. Responding object 5604 is made property Vesponder* of new user-defined frame 5602. Property 
"procedure" of the method object selected in step 5524 is procedure 5606 and is made property "procedure" 
of new user-defined frame 5602. Property "position" of user-defined frame 5602 is initialized to be an Integer 
5608 whose value is zero. And property "stack" is Initialized to an empty stack 5610. 
5 Once new user-defined frame 5602 is created, processing transfers from step 5526 to step 5528 in which 

objects are moved from stack 5410 of user-defined frame 5304 to stack 5610 of user-defined frame 5602. 
Objects are moved from stack 5410 to stack 5610 such that the order of objects is preserved. In other words, 
the topnrrast argument on stack 5410 is at the top of stack 5610, and the bottommost argument on stack 5410 
Is at the bottom of stack 5610. Each object is moved according to property "passage" of the corresponding 
10 constraint of property "aiguments" of the retrieved operation def lnitk>n. 

If property "passage" is "byRef. the reference to the object is popped from stack 5410 and is pushed on 
to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 has the same access to the argument 
as does procedure 5406 of requesting user-defined frame 5304. 

If property "passage" is "byProtectedRer. the reference to the object Is popped from stack 5410, is made 
IS a protected reference, and is pushed on to stack 5610. Thus, procedure 560a of new user-defined frame 5602 
cannot alter the argument and the argument is therefore "readonly". 

If property "passage" Is "byUnprotectedRer. whether the reference to the argument on stack 5410 of re- 
questing user-defined frame 5304 is protected is determined. Such a determination is nnade by querying at- 
tribute "isProtected" which is described more completely In Appendbc A If the reference is protected, an ex- 
20 ception of class "Reference Protected" is thrown. Otherwise, the reference is popped from stack 5410 and is 
pushed on to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 is provided access to alter 
the argument passed by ur {protected reference. 

If property "passage" is "byCopy". a copy is nrade of the object found on stack 5410 and an unprotected 
reference to the copy is pushed on to stack 5610 of new user-defined frame 5602. Thus, procedure 5606 is 
25 given unrestricted access to a copy of the argument, which is passed by copy, but has no access to the argu- 
ment Itself. 

Thus, new user-defined frame 5602 is complete and represents the dynamic state of the subject operation 
immediately preceding perfomiance of the subject operatton. Processing transferefrom step 5528 (Figure 55) 
to step 5530 in which new user-defined frame 5602 is included in the execution state of process 5300 by being 
30 pushed on to stack 5302 (Figure 56C). Thus, stack 5410 and the method object whose property "procedure" 
is procedure 5406 are no longer the current stack and current method, respectively. Stack 5610 is the current 
stack and the method object whose property "procedure" is procedure 5606 is the current method. Processing 
transfers from step 5530 (Figure 55) to step 5532. In step 5532, procedure 5606 (Figure 56C) of user-defined 
frame 5602 is performed. 

35 As performance of procedure 5406 executes an identifier which Invokes performance of the subject op- 
eratton and the creatbn of user-defined frame 5602, performance of procedure 5606 of user-defined frame 
5602 can execute identifiers which invoke further operations thereby creating further frames which are sub- 
sequently pushed on to stack 5302 and whose procedures are subsequently performed. Thus, the execution 
state of process 5300 is represented by one or more frames on stack 5302, which is property "frames" of proo- 

40 ess 5300 representing a thread of execution. 

After performance of procedure 5606, user-defined frame 5602 represents the dynamic state of the sub- 
ject operation immediately following performance of the operation. Stack 561 0 of user-defined frame 5602 con- 
tains the result, if any. produced by performance of the subject operation. Processing transfere from step 5532 
(Figure 55) to step 5534 in whk:h property "resuir of the operation definition defining the subject operation is 

45 produced by querying attribute "result" of the operation definition. Processing transfisrs from step 5534 to result 
test step 5536. in which the memberehip of property "result" in class "Constrainr is determined. In other words, 
property "result" is verified to be a constraint and not a nil. If property "resuir is a constraint and not a nil. the 
subject operation produces a result and processing transfers from result test step 5536 to a stack empty test 
step 5538. 

50 In stack empty test step 5538. the engine interpreting process 5300 (Figure 56C) determines whether an 
object is present on stack 5610. If stack 5610 is empty, processing transfers from stack empty test step 5538 
(Figure 55) to terminal step 5540. In terminal step 5540, an exception of daas 'Result Missing" is thrown. If 
stack 5610 (Figure 56C) contains an object, processing transfere from stack empty test step 5538 (Figure 55) 
to dass of result test step 5542. In class of result test step 5542, the engine interpreting process 5300 (Figure 

55 56C) determines whether the object on stack 561 0 satisfies the constraint that is property "resuir of the op- 
eratton definition. If the object does not satisfy the constraint processing transfere from dass of result test 
step 5542 (Figure 55) to terminal step 5544. In terminal step 5544. an exceptton of dass "Result Invalid" is 
thrown. If the object satisfies the constraint, processing transfere from dass of result test step 5542 to step 
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5546. 

In step 5546, the object is moved from stack 561 0 (Figure 56C) of user-defined frame 5602 to stack 541 0 
of user-defined frame 5304 according to property "passage" of the operation definition as descrit>ed above. 
Processing transfers from step 5546 (Figure 55B) to step 5548. 

It in result test step 5536, property "result" is nil, processing transfers directly to step 5548. In step 5548, 
new user-defined frame 5602 is popped from stack 5302 (Figure 56B) and discarded (Figure 56A) . Thus, stack 
5410 and the method object whose property "procedure" is procedure 5406 are again the current stack and 
the cunrent method, respectively. Processing transfers from step 5548 (Figure 55B) to step 5550 in which exe- 
cution of procedure 5406 is continued by incrementing integer 6408 and executing the item of procedure 5406 
at the positton indicated by integer 5408. Thus, execution of an identifier which references an operation causes 
performance of the operation. 



Operation Definition and Method Selection 



As discussed above, an operation definition and a method object, which together define the subject op- 
eration, are selected in steps 5510 and 5524. respectively (Figure 55A). The selectk)n of the operatton defini- 
tion and method are described in the context of the embodiment of the present invention described above with 
respect to Figure 418. In that embodiment, class object 4102 is formed by replicating properties "citation", "in- 
terface" and "implementation" of class definition 4100. The selected operation definition is selected from an 
interface object, and the selected method object is selected from an implementation object. The operation def- 
inition and method object are each selected according to logic flow dicgram 5700 (Figure 57). 

The operation definition and method object, which are appropriate, depend on the class of which the re- 
sponding object is an instance. The responding object is examined to determine whether the responding object 
is a class object, i.e., is a member of class "Class" in a dass test step 5702. If the responding object is a dass 
object, processing transfers from dass test step 5702 to a dass lookup step 5704, In dass lookup step 5704. 
property "dassFeatures" of the responding object and the interface superclasses of the responding object are 
searched as discussed below. The lexicon of dass features, i.e., property "dassFeatures", is searched for a 
key which matches the identifier of the subject operatton, i.e., the executing identifier. Additionally, in dass 
lookup step 5704. property "dassMethods" of the responding object and the implementation superclasses of 
the responding object are searched, as discussed below, for a method object associated with the executing 
identifier. 

Processing transfers from dass lookup step 5704 to a test step 5706 in which the engine interpreting the 
current process, e.g., process 5300 (Figure 56A). determines whether an operatton definition and a method 
object are found in dass lookup step 5704. If an operation definition and a method object defining the subject 
operation are found, processing transfers from test step 5706 to terminal step 5708 where the selection process 
terminates. Otherwise, processing transfers from test step 5706 to instance lookup step 5710. Additionally, if 
the responding object is not a dass object, i.e.. is not a member of class "Class", processing transfers directly 
from dass test step 5702 to instance lookup step 5710. 

In instance lookup step 571 0. property "instanceFeatures" of the interface object of the dass of which the 
responding object is an instance and of the interface objects of the interface superdasses of that dass are 
searched for a feature definition associated with the executing identifier. Also in instance lookup step 5710, 
property "instanceMethods" of the implementatton of the dass of which the responding object is an instance 
and of the implementattona of the implementatton superdasses of that dass are searched for a method object 
associated with the executing identifier. The order in which superdasses are searched is discussed below. 

It should be noted that if the responding object is a dass object, a dass method can only implement a 
class feature and an instance method can only implement an instance feature. 

Processing transfers from instance lookup step 6710 to a second test step 5712 in which the engine de- 
termines whether an operation definition and a method object are found in instance lookup step 5710. If an 
operation definitfon and method object identified by the executing identifier are found, processing transfers 
from second test step 5712 to terminal step 5716. In terminal step 5716, the selection process tenminates suc- 
cessfully. Otherwise, processing transfers from second test step 5712 to tenninal step 5714. In terminal step 
5714. an exception of dass "Feature Unavailable" is thrown. 

Portions of the predefined hierarchy, which is disdosed in Appendix A which discussion is incorporated 
herein in its entirety by reference, are shown in Figures 58A and 58B to illustrate the order in which various 
classes are searched for appropriate operation definitions and method objects. While Figure 58A and 58B show 
portions of the predefined interface hierarchy, the method by which the implementation hierarchy is searched 
is as described below with respect to the searching of the interface hierarchy. 

Hierarchy graph 5800 (Figure 58A) shows dass object 5802 representing dass "Lisr, Class "List" inherits 
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from mix-in superclass "Ordered" and flavor superclass "Collection" represented by dass objects 5804 and 
5806. respectively. Class "Collection" Inherits from superclass "Object" represented by dass object 5808. 
Class "Objecr inherits from mix-in superclass "Referenced" represented by class object 5810. In Figures 58A 
and 58B, (i) double lines are drawn between flavor classes and subdasses of the flavor classes, (ii) single 
5 solid lines are drawn between mix-in dasses and subdasses of the mix-in dasses. and (iii) a dashed line is 
drawn between a dass and an instance of the class. As discussed above, the last item of property "superclass- 
es" of either an interface object or an implementation object must not identify a mbc-in dass. The reason for 
this is discussed below. 

Suppose for illustratton purposes that the responding object in the context of logic flow diagram 5700 (Fig- 
to ure 57) is dass object 5802 (Figure 58A) representing dass "List". In dass lookup step 5704 (Figure 57). prop- 
erty "classFeatures" of the interface object, which is property "interface" of class object 5802, is searched for 
an association whose key is the executing identifier. If such an association is found, the feature definition as- 
sociated with the identifier is an operation definition which defines the interface of the subject operation and 
is selected and the search for an operatbn definition condudes. 
15 If, however, no such association is found, the interface object of the first superdass of dass "List", namely, 
class "Ordered" is searched in the same mannerfor an appropriate operation definition. If no appropriately iden- 
tified operation definitbn is found, the superclasses of dass "Ordered" are searched in a depth-first walk of 
the interface hierarchy. Since class "Ordered" has no superdasses. the next item of property "superclasses" 
of the interface object of dass 'Lisf, i.e., dass "Collection", is searched as described above. Since the last 
20 superdass searched is not a mbc-in dass. every mix-in superclass is searched before the flavor superdass is 
searched. 

Thus, in the manner described above with respect to dass "List", the remainder of the class objects of Fig- 
ure 58A are searched in the following order dass object 5808 representing class "Objecf and class object 
581 0 representing dass "Referenced". ' 

25 The search for an appropriate method object defining the implementation of the subject operation is as 
described above for the search for an appropriate operation definition with two exceptions. First, property 
"dassMethods" of the implementatton object of a dass is searched for an appropriately identified method ob- 
ject Second, the implementation superdasses, rather than the interface superdasses. of dass "List" are 
searched for an appropriately identified method object 

30 The importance of the single flavor superclass being the last superdass searched is apparent if one con- 

siders the following hypothetical example. Suppose, for example, that dass object 5806, which represents fla- 
vor "Collection", and dass objects representing superclasses of dass "Collection" are searched before search- 
ing dass object 5804, which represents mix-in class "Ordered". Suppose further than dass object 5808, which 
represents class "Object", defines one or more features which are adapted by dass "Ordered". i.e., whose 

35 methods are supplied by dass object 5804. Since dass object 5808, in this hypothetical example, will always 
be searched before dass object 5804. the method for any feature defined by dass object 5808 will always be 
found in dass object 5808. It would therefore be impossible for dass object 5804 to adapt any feature defined 
by dass object 5808. Therefore, the flavor superdass of a flavor is always the last superdass of that flavor 
that is searched for an operatton definition or method. 

40 Continuing in the illustrative example in whk:h the responding object in the context of logic flow diagram 
5700 (Figure 57) is dass object 5802 (Figures 58A and 58B) representing dass "List", hierarchy graph 5850 
(Figure 58B) shows the dasses searched in instance lookup step 571 0 (Figure 57). The search for an operation 
def initbn and method object for an instance feature of dass object 5802 (Figure 58B) differa from the search 
for an operation definition and method objectfor a dass feature as described above in two ways. Firat, property 

45 "instanceFeatures* of the interface object of a dass is searched for an appropriately identified operation def- 
inition, and property "instance Methods" of the implementatk)n object of a dass is searched for an appropriately 
identified method object Second, the dasses of which the responding object, i.e., dass object 5802, is a mem- 
ber are searched. 

The manner in which the dasses are searched is equivalent to that described above and is not repeated 
50 here. The following dasses are searched in the following order until an appropriate operation definition and 
method object are found or until all dasses which follow have been searched: (i) dass object 5812 representing 
dass "Class" of which dass object 5802 is an instance; (ii) dass object 581 8 representing class "Interchanged", 
a mix-in superdass of class "Class"; (iii) dass object 581 8 representing class "Unchanged", a mix-in superdass 
of mix-in dass "Interchanged" and therefore of dass "Qass"; (iv) dass object 5814 representing dass "Cited", 
55 a mix-in superdass of dass "Qass"; (v) dass object 5808 representing dass "ObjecT. a flavor superdass of 
class "Class"; and (vi) dass object 581 0 representing dass "Referenced", a mix-in superclass of dass "Object". 

If no operation definition or no method object associated with the executing identifier is found in searching 
the dasses of Figures 58A and 588. the operatton is not defined for the responding object and an exception 
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of dass 'Feature Undefined" is thrown. 

As described above, if the responding object is not a dass. dass lookup step 5704 (Figure 57) is skipped. 
For example, if the responding object is list 5802A which is an instance of dass "Lisr, the dasses shown in 
hierarchy graph 5800 (Figure 58A) are searched in instance lookup step 5712 (Figure 57) as described above. 

In one embodiment of the present invention, the interface and implementation hierarchies are independent 
In other words, an interface superdass of a dass is not necessarily an implementation superclass of the dass. 
and an implementation superdass of a dass is not necessarily an interface superdass of the dass. An engine 
ensures that no feature definition is without an implementation, in such an embodiment during performance 
of operation "makeClasses". Operation "makeClasses" falls, throwing an exception of dass "Class Exceptton", 
upon the following condition: the dass defined is not abstract and the dass defined does not define, or inherit 
from implementation superdasses, a method which implements a defined feature. Thus, a feature defined in 
the interface hierarchy is always implemented by a method found in the implementation hierarchy. 

Thus, an appropriate operatton definition and method object for the subject operation are found by search- 
ing the class hierarchy as discussed above or an exception is thrown. 

Escalatk)n 



As discussed above, a dass which inherits a feature from a superclass can supersede the implementation 
of the feature by providing a new implementation for the feature. However, the new implementation may need 
20 to use the implementation provided by the superdass. An object is directed to perform a feature as implement- 
ed by a particular one or by any one of the immediate superdasses of the current dars by escalating the fea- 
ture. As described more completely in Appendix A, the current dass is the dass which provides the currently 
executing method. 

A feature is escalated by executing a qualified identifier which references the feature to be escalated or 
25 by executing an "escalate" selector. Aqualif ied identifier Indudes property "qualifier" which identifies the dass 
which is to provide the implementatton of the feature. If a feature is escalated by execution of an "escalate" 
selector, any immediate implementation superdass can provide the implementation of the feature. 

It should be noted that no attribute is defined which provides access to property "qualified of a qualified 
identifier. Property "qualifier of a qualified identifier is set when the qualified identifier is created and remains 
30 unaltered until the qualified identifier is destroyed. Escalation of a feature is discussed further in Appendix A. 
Escalation plays a partfcularly important role in initializing objects. Appendix A indudes a description of 
an initialization for each predefined dass of the present inventton. The initialization of an object is shown by 
logic flow diagram 5900 (Figure 59) which is discussed in the Illustrative context of the initialization of a list 
i.e. an instance of dass "List". Operation "Initialize" is escalated for each immediate Implementation superdass 
35 of class "LIsr. As discussed above, hierarchy diagram 5800 (Figure 58A) represents the interface superdasses 
of dass "LIsr Hierarchy diagram 5800 also accurately represents the Implementatton superdasses of dass 
"Lisr. 

Operation "initialize", as defined by the dass of which the new list is an instance, i.e. dass "Usr. is per- 
formed in step 5902. Perfonrance of operation "initial ize" consumes zero or more arguments from the current 
^ stack. Processing transfers from step 5902 to step 5904. In step 5904. property "superclasses" of the imple- 
mentation object of dass "List" is produced by querying attribute "superdasses" of the implementatton object 
As described above, property "superdasses" of an implementation object is a list of identif iere which reference 
classes. Processing transfere from step 5904 to for each superdass step 5906. 

For each superdass step 5906 and next step 591 0 define a loop in which each superclass of property "su- 
45 perdassea" produced above is processed in an escalate step 5908. Thus, for each superdass. processing 
transfere from for each superdass step 5906 to escalate step 5908. In escalate step 5908, the superdass is 
directed to perform operation "initialize", according to logto flow diagram 5900. Thus, logic flow diagram 5900 
is perfonned recureively in a depth-f iret walk of the implementation hierarchy. For example, the firet immediate 
superdass, to which "initialize" is escalated in escalate step 5908, (i) performs "initialize" in step 5902, (li) pro- 
so duces immediate implementation superdasses of the superdass in step 5904 and (iil) escalates "initialize" to 
each superdass of the superdass in the loop defined by for each superclass step 5906 and next step 5910. 

Processing transfere from escalate step 5908 through next step 5910 to for each superdass step 5906. 
Thus, initialization is escalated to each immediate implementation superdass in the order found in the list that 
is property "superdasses". Each performance of operation "initialize" by a superdass of class "List" consumes 
zero or more arguments from the current stack and escalates the initialization to the immediate implementation 
superdasses of the superdass. 

Once each immediate implementation superdass of dass "LIsr has performed operation "initialize" ac- 
cording to the loop offer each superdass step 5906 and next step 5910. processing transfers from for each 
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superclass step 5906 to terminal step 5912. In terminal step 5912, performance of operation "initialize" as de- 
fined by class "List" completes successfully. Thus, each dass of which the new list is a member performs op- 
eration "initialize" in the order in which classes are searched in instance lookup step 5710 (Figure 57) described 
above. 

5 

Execution of Modifiers 

The execution of an identifier is discussed at length above and in Appendbc A. However, the presence of 
a modifier or the nature of the identifier can alter the execution of the identifier. For example, according to 
10 the modifier substitution rules discussed in Appendbc A, if the identifier identifies an attribute, operation "ge- 
tAttribute" is performed consuming as the sole argument the executing identifier. The various modifiers and 
the effects on the execution of an identifier are discussed in Appendix A and such discussion is hereby incor- 
porated by reference. 

15 Execution of Selectors 

A selector is a primitive whose execution causes a special action. While each selector is discussed in Ap- 
pendix A, several selectors are discussed herein. For example, selectors "break", "continue" and "succeed" 
are discussed below in the context of performing procedures. Execution of selector "seir pushes on to the cur- 

20 rent stack a reference to the current object, i.e. the responder of the current method. In the context of Figure 
56C, the current object is object 5604 which is property "responder" of frame 5602, the cun-ent stack is stack 
5610 which is property "stack" of frame 5602. and the cu.Tent method is the method object whose property 
"procedure" is procedure 5606. Execution of selector "process" pushes on to the current stack a reference to 
the current process. In Figure 56C, the current process is process 5300, If the current process is an engine 

25 place, a nil is pushed on to the cunnent stack. 

Thus, an engine created according to the present invention executes procedures by sequential execution 
of the items of the procedures. Execution of an item of a procedure when that item is an identifier causes exe- 
cution of the feature referenced by the identifier under the circumstances described above. The dynamic state 
of a procedure being performed is recorded in a frame. Dynamic states of methods implementing features 

30 which are user-defined are recorded in user-defined frames. A feature definition and a method object defining 
the interface and implementation, respectively, of the feature are selected from the classes of which the re- 
sponding object is a member. Implementations provided by superclasses of the current dass are perfbnned 
by escalating the feature. For example, operation "initialize" is recursively escalated such that the method pro- 
vided by each dass of which the responder is a member Is performed. Modifiers are used to alter the execution 

35 of an identifier. And selectors provkle a simple means by which commonly performed complex actions are 
caused by executton of a single object These features combine to provide a great degree of functionality and 
generality in the disclosed set of computer instructions. 

Control Constructs 

40 

As discussed above, an agent can apply sophisticated logic to determine to which place or places to travel 
and with which agent or agents to meet. The disclosed instruction set provides a number of instructions which 
provide a large degree of generality enabling the realization of complex and sophisticated logic in procedures 
constructed of the disclosed instruction set The following control constructs which provide such a targe degree 
46 of generality are discussed: (i) resources and resource allocation features provkJe processes with the ability 
to obtain and maintain shared or exdusive control of a resource during performance of a procedure; (ii) decision 
handling features enable processes to conditionally perfonm procedures; (ill) exceptk)n handling features en- 
able processes to detect and take action upon the throwing of an exception; and (iv) looping features enable 
a procedure to repeatedly perfonm a procedure to thereby efficiently perform repetitive tasks. 

so 

Resource and Resource Allocation Features 

As discussed above and in Appendix A. an engine processing one or more processes does so concurrently. 
For example, engine 132B (Figure 15E) concurrently processes agents 150Aand 150B. At any point during 
55 performance of a first procedure by agent 1 50A carried out by engine 1 32B, engine 1 328 can temporarily sus- 
pend performance of the first procedure by agent 150A. Engine 132B is then free to carry out perfonnance 
of a second procedure on behalf of agent 150B. At any point during performance of the second procedure, en- 
gine 132B can temporarily suspend performance of the second procedure on behalf of agent 150B and resume 
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performance of the first procedure on behalf of agent 150A. In this manner, engine 132B concurrently proc- 
esses agents 150Aand 150B, 

As discussed in Appendix A, an engine canries out performance of most of the predefined features atom- 
ically. A feature is performed atomicaliy if the engine refuses to suspend performance of the feature for the 
5 purpose of processing another process until the feature has completed successfully or failed. When a feature 
is performed atomicaliy, no process but the current process can alter or manipulate resources since no other 
process will be interpreted during performance of the feature. Those predefined features which are not per- 
formed atomicaliy are discussed in Appendix A. 

There is no mechanism for causing a user-defined feature to be performed atomicaliy. Thus, a mechanism 
10 is needed to enable a process to obtain shared or exclusive use of a resource during performance of a user- 
defined feature or a predefined feature which is not performed atomicaliy. A user is able to configure a process 
to obtain shared or exclusive use of a resource by use of operation "use" which is defined by dass "Resource" 
and is described in detail in Appendix A. The dynamic state of a performance of operation "use" is recorded 
by a use frame of class "Use Frame". Use frames are discussed in Appendix B. 

15 

Conditional Execution of Executed Objects 

An executed object is executed conditionally by performance of operation "if or operation "either". Per- 
formance of operation '\f by a responding executed object consumes a boolean object and perfonms the exe- 

20 cuted object if the value of the boolean object is "true." It should be noted that procedures gre executed objects, 
i.e., members of mbc-in class "Executed", and that the performance of a procedure is discussed above with 
respect to Figures 52A and 52B. 

Logic flow diagram 6000 (Figure 60) shows the implementation of operation "ir as defined by.mix-in dass 
"Executed". In performing operation "if, the responding executed object pops a boolean object from the current 

25 stack in step 6002. Processing transfers from step 6002 to a boolean test step 6004, in which the boolean object 
popped in step 6002 is compared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6004 to step 6006 in which the responding executed object is performed. Processing transfers from 
step 6006 to exception test step 6010 in which the engine carrying out performance of operation "ir determines 
whether execution of the responding executed object in step 6006 threw an exception. 

30 If no exception is thrown in step 6006. processing transfers from exception test step 601 0 to terminal step 
6008. Additionally, processing transfers from boolean test step 6004 directly to terminal step 6008 if the boo- 
lean object Is "false". In terminal step 6008. operation "ir completes successfully. If an exception is thrown in 
step 6006. processing transfers from exception test step 6010 to terminal step 6012 in which any exception 
thrown by performance of the responding executed object in step 6006 is thrown, causing operation "ir to fail. 

35 The dynamic state of a performance of operation "ir is recorded by a predefined frame, i.e. a member of dass 
"Predefined Frame", which is discussed above and in Appendbc B. 

One of two executed objects is selected and executed by use of operation "either". An executed object 
performs operation "either* by consuming a second executed object and a boolean object and causing exe- 
cution of the responding executed object if the boolean object's value is "true" and. causing execution of the 

40 second executed object if the boolean object's value is false." Logic flow diagram 61 00 (Figure 61) shows the 
implementation of operation "either" as defined by mix-in dass "Executed". 

The responding executed object pops from the current stack a second executed object in step 6102. Proc- 
essing transfers from step 6102 to step 6104 in which the responding executed object pops from the current 
stack a boolean object Processing transfers from step 6104 to boolean test step 6106 in which the boolean 

46 popped in step 6104 Is compared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6106 to step 6108 in which the responding executed object is performed. Conversely, If the value of 
the responding bK>oiean object is false", processing transfers from boolean step 6106 to step 6110 in which 
the second executed object is performed. Processing transfers from step 6108 or step 6110 to terminal step 
6112. In terminal step 6112. operation "either* terminates, throwing any exception thrown in step 6108 or step 

50 6110. The dynamic state of an executed object performing operation "either" is recorded by a predefined frame. 
An executed object is selected from one or nf>ore executed objects and performed by perfomiance of op- 
eration "select". Operation "select" is defined by class "Objecr and is performed by an object identifying the 
particular executed object to be performed. Figures 62A and 62B show the interface of the operation "select". 
Figure 62A shows the state of predefined frame 6200 which records the dynamic state of operation "select" 
55 as performed by object 6204. Predefined frame 6200 is part of the execution state of a process (not shown) 
and is shown immediately prior to performance of operation "select". 

Object 6204 is the responder. Predefined frame 6200 has no property "responder" which identifies object 
6204. Instead, object 6204 is identified as the responder by its position within property "procedure" of the frame 
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(not shown) immediately below the current frame on the stack (not shown) that is property frames" of the cur- 
rent process. Object 6204 is the item of that procedure (not shown) whose position is one less than property 
"position" of that frame. For example, the responder of user-defined frame 5602 (Figure 56C) is the item of 
procedure 5406 whose position is one less than the value of integer 5408. 

5 Stack 6202 (Figure 62A) is the current stack. On stack 6202 are a mark, whose positron is indicated by 

letter "M" and which delineates the arguments of the operation, and one or more pairs of objects and associated 
executed objects. For example, stack 6202 contains from top to imnnediately above the mark, object 6206, exe- 
cuted object 6208, object 621 0, executed object 6212, nil 6214, and executed object 6216. Objects 6206, 6210 
and nil 6214 are associated with respective executed objects 6208, 6212 and 6216. 

10 The Implementatton of operatton "select" Is shown by logic flow diagram 6300 (Figure 63). In step 6302. 
objects 6206-7616 (Figure 62A) and the nrrark are popped from stack 6202, Processing transfers from step 
6302 to step 6304 in which a dictionary is fornied whose keys are objects 6206. 6210 and nil 6214 and whose 
associated values are respective executed objects 6208, 6212 and 6216. Processing transfers from step 6304 
to step 6306. In step 6306, the executed object whose associated key is equal to responding object 6204 is 

15 retrieved from the dictionary formed in step 6304. The retrieval of a value of a dictionary given a key of the 
dictk)nary is described in detail in Appendbc A. 

Processing transfers from step 6306 to a test step 6308. In test step 6308, the engine carrying out per- 
formance of operation "selecr determines whether an executed object is successfully retrieved from the dic- 
tionary. If an executed object associated with a key equaf to responding object 6204 is found within the dic- 

20 tionary and retrieved, processing transfers to step 6314. In step 6314, the retrieved executed object is per- 
formed. Processing transfers from step 631 4 to exceptk>n test step 63 1 6 in which the engine determines wheth- 
er the performance of the executed object completed successfully in step 6314. 

If perfonmance of the executed object in step 6314 fails and throws an exceptton, processing transfers 
from exception test step 6318 to terminal step 6320. In tenninal step 6320. the exception is thrown, causing 

25 operation "select" to fait. If, on the other hand, the retrieved executed object is performed successfully in step 
6314, processing transfers from exception test step 6318 to terminal step 6316. In terminal step 6316. oper- 
ation "select" completes successfully. 

In test step 6308. if no key equal to responding object 6204 is found in the dictionary formed in step 6304, 
processing transfers from test step 6308 to step 6310. In step 6310, the executed object contained within the 

30 dictionary whose associated key is a nil, e.g., executed object 621 6 associated with nil 6214, is retrieved. Proc- 
essing transfers from step 631 0 to a second test step 631 2 in which the engine determines whether an executed 
object is successfully retrieved in step 631 0. If an executed object within the dictbnary with an associated key 
that is a nil is found and successfully retrieved, processing transfers from second test step 6312 to step 6314 
which performs the executed object as described above. 

35 If. on the other hand, no executed object is retrieved in step 631 0. no key equal to object 6204 and no key 
that is nil is found in the dictionary and processing transfers from second test step 6312 to terminal step 6316. 
As described above, in terminal step 6316. operation "select" completes successfully. Thus, if no executed 
object is associated with a key equal to the responding object or is associated with a nil, operation "select" 
completes successfully without performing any executed object in the dictionary. 

40 Figure 62B shows the state of select frame 6200 immediately following performance of operation "select" 
by responding object 6204. Performance of operate n "select" produces no result as shown by empty stack 
6202 of Figure 62B. 

An executed object is executed repeatedly so long as a condition is met by perfonmance of operation 
"while". The dynamic state of a performance of operation "while" is recorded in a predefined frame 6402 (Figure 

45 64). Executed object 6404 is the responder of operation "while" and is the responding executed object Exe- 
cuted object 6404 is property "procedure" of predefined frame 6402. Executed object 6406 is property "pre- 
condition" of predefined frame 6402 and is the executed object consumed as an argument as discussed below. 

Operation "while" is performed by responding executed object 6404 which consumes as an argument exe- 
cuted object 6406. Performance of operation "white" is illustrated by logic flow diagram 6500 (Figure 65). In 

50 step 6502, executed object 6406 is popped from the current stack. Processing transfers from step 6502 to step 
6504, in which executed object 6406 is performed. Perfonmance of executed object 6406 in step 6504 pushes 
on to the current stack a boolean which indk^ates whether responding executed object 6404 is to be performed. 

Processing transfers from step 6504 to exception test step 6506 in which the engine carrying out perfor- 
mance of operation "while" determines whether perfonmance of executed object 6406 throws an exceptton. If 

55 performance of executed object 6406 throws an exception, processing transfers from exception test step 6506 
to terminal step 6508 in which the exceptbn Is thrown by operatton "while" causing operatton "while" to fail. 
If, on the other hand, executed object 6406 is performed successfully, processing transfers from exceptton 
test step 6506 to step 6510. 
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In step 651 0, a boolean is popped from the current stack. Processing transfers from step 651 0 to true test 
step 6512. In true test step 6512. the boolean popped from the current stack is compared to true", tf the boo- 
lean is "true", processing transfers from true test step 6512 to step 6514 in which responding executed object 
6406 is performed. Processing transfers from step 6514 to a second exception test 6516 in which the engine 

5 determines whether performance of executed object 6404 throws an exception. 

If performance of executed object 6404 in step 6514 throws an exception, processing transfers from seo- 
ond exception test step 6516 to a continue test step 6522. In continue test step 6522. the thrown exception is 
compared to an internal exception "continue", which is thrown by execution of selector "continue" as described 
below and in Appendix A. As described below in greater detail, execution of selector "continue" terminates an 

10 iterative performance of a procedure and initiates a new iterative performance of the procedure. If the exception 
thrown in step 6514 is internal exception "continue", processing transfers from continue test step 6522 to step 
6504, which is described above. 

Conversely, if the exception thrown in step 6514 is not internal exception "continue", processing transfers 
from continue test step 6522 to a break test step 6524. In break test step 6524, the exception thrown in step 

15 6514 is compared to an internal exception 'break", which is thrown by execution of selector "break" as descri- 
bed below and in Appendix A. As described below in greater detail, executfon of selector "break" terminates 
an iterative performance of a procedure without initiating a new iterative performance of the procedure. If the 
exception thrown in step 6514 is internal exceptran "break", processing transfere from continue test step 6522 
to terminal step 6520, in which operation "while" completes successfully as described below. 

20 Conversely, if the exception thrown in step 6514 is not internal exception "break", processing transfere 

from break test step 6524 to terminal step 6518. In terminal step 6518. the exception thrown in step 6514 is 
thrown causing operatk)n Vhile" to fall. 

If, on the other hand, performance of executed object 6404 succeeds and no exception is thrown in step 
6514. processing transfere from second exceptton test step 6516 to step 6504 in which executed object 6406 

25 is again performed. 

Performance of steps 6504. 6506. 6510. 6512, 6514, 6516, and 6522 is repeated until performance of exe- 
cuted object 6406 produces a boolean whose value is "false" or until an exception is thrown in step 6508 or 
step 6518. If perfonmance of executed object 6406 produces a boolean that is "false", processing transfere 
from true test step 6512 to tenninal step 6520 in which operation "while" completes successfully. Thus, pro- 
30 cedure 6406 is repeatedly performed while perfomnance of executed object 6406 produces a "true" boolean. 
Thus, operations "ir, "either", "selecT and %vhile" provide the disclosed set of computer instructions sub- 
stantial decision making capabilities. 

Exception Handling Features 

35 

As discussed In greater detail in Appendbc A, an executed object which performs operatton "do" is thereby 
performed, and If performance of the executed object throws an exception, the exception is thrown by oper- 
ation "do", causing operatton "do" to fail. The propagation of exceptions is illustrated in steps 5210 and 5212 
of logic flow diagram 5200 (Figure 52A) as discussed above. Failure of a perfonmance of an executed object 

40 generally causes the failure of any executed object Invoking, either directly or indirectly, the performance. Any 
exception which causes operation "live" of a process to fail causes de3tructk>n of the process. It is therefore 
preferred that instructions be provided which detect and prevent the propagation of exceptions. 

Afirst executed object, e.g., a procedure, invoking the performance of a second executed object is capable 
of preventing failure of the first executed object due to an exceptton thrown by the second executed object by 

46 "catching" any exception thrown by the second executed object To "catch" an exception is to detect the throw- 
ing of the exception and to direct that specif k: action be taken in such an event An exception which is thrown 
by the second executed object and which Is caught by the firet executed object does not cause the f iret exe- 
cuted object to fail. 

An exception thrown by perfomtance of an executed object is caught by causing performance of the exe- 
so cuted object by use of operation "catch" in the place of operation "do". An executed object whose perfomiance 
is caused by operation "catch", is performed as If the executed object were performing operation "do" except 
that certain exceptions thrown by performance of the executed object do not cause operation "catch" to fail, 
in such a case, the exception ts pushed on to the current stack and returned as a result 

The interface of operation "catch" is shown by Figures 66A and 66B. Figure 66A shows the state of catch 
55 frame 6602. which records the dynamic state of operation "catch" as defined by mix-in dass "Executed", im- 
mediately prior to performance of operation "catch" by executed object 6604. Catch frame 6602 is part of the 
execution state of a process (not shown). Executed object 6604 is the responding executed object and is prop- 
erty "procedure" of catch frame 6602. Performance of operation "catch" consumes a single argument class 
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object 6608 which is at the top of stack 6606. Stack 6606 is the current stack. Stack 6606 is property "stack" 
of the topmost user-defined frame (not shown) below catch frame 6602 on the stack (not shown) that is prop- 
erty "frames" of the cunrent process. Class object 6608 represents dass "Exception" or a subclass thereof. 
The implementation of the operation "catch" is shown by logic flow diagram 6700 (Figure 67). Class object 

5 6608 is popped from stack 6606 and thereby consumed in step 6702. Processing transfers from step 6702 to 
step 6704 in which executed object 6604 is performed. Processing transfers from step 6704 to exception test 
step 6706 in which the engine carrying out performance of operation "catch" determines whether performance 
of executed object 6604 throws an exception. If perfonnance of executed object 6604 does not throw an ex- 
ception, processing transfers from exception test step 6706 to step 6708. In step 6708. a nil is pushed on to 

10 stack 6606. Processing transfers from step 6708 to terminal step 6710 in which operation "catch" completes 
successfully. 

If executton of executed object 6604 in step 6704 fails and throws an exceptton, processing transfers from 
exception test step 6706 to member test step 6712. In member test step 6712. the engine checks membership 
of the exception thrown in step 6704 in the dass represented by dass object 6608. Jf the thrown exception is 
15 not a member of the class represented by class object 6608. processing transfers from member test step 6712 
to terminal step 6714. In terminal step 6714. the exception thrown in step 6704 is thrown by operation "catch" 
and operatton "catch" fails. 

If the thrown exception is a member of the dass represented by dass object 6608, processing transfers 
from member test step 6712 to step 6716. In step 6716, the exception thrown in step 6704 is pushed on to 
20 stack 6606 and processing transfers from step 6716 to terminal step 6710. As described above, in terminal 
step 6710, operation "catch" completes successfully. Thus, the thrown exception is caught, and operation 
"catch" succeeds and does not propagate the thrown exception. 

Figure 66B shows the state of catch frame 6602 immediately following perfonnance of operation "catch" 
by procedure 6604. At the top of stack 6606 is exception 6610 which is the exception thrown by performance 
25 of procedure 6604 if performance of procedure 6604 failed. In such a case, exception 6610 is a member of 
the dass represented by dass object 6608 (Figure 66A). In place of exception 6610 (Figure 66B) on stack 6606 
is a nit (not shown) If performance of procedure 6604 succeeded. Thus, the disdosed set of computer instruc- 
tions is provided with means for detecting and handling exceptions. 

30 Looping Features 

The disdosed computer instruction set provides means for repeatedly performing an executed object, e.g., 
a procedure, facilitating performance of repetitive tasks. Operation "while" discussed above is one example 
of a looping feature. Additionally, an executed object is performed repeatedly using operations "loop" and "re- 
35 pear. 

Operation "loop" performs an executed object indefinitely by repeatedly performing the responding exe- 
cuted object Performance of operation loop" by an executed object consumes no arguments and produces 
no result Performance of operation "repeat" by an executed object consumes an integer argument and pro- 
duces no result, performing the responding executed object a number of times equal to the value of the integer 

^ argument consumed. Each performance of the responding executed object in the course of performing oper- 
atton "loop" or operation "repeat" is herein called an "iterative performance" of the executed object 

Logic flow diagram 6800 (Figure 68) shows the implementation of operation "loop" as performed by the 
responding executed object The responding executed object is performed in step 6802. Processing transfers 
from step 6802 to exceptton test step 6804 in which the engine carrying out performance of operation "loop" 

45 determines whether performance of the responding executed object throws an exception. If no exception is 
thrown, i.e.. if the responding executed object is performed successfully, processing transfers from exceptton 
test step 6804 to step 6802 in whteh the responding executed object is performed again. Otherwise, if perfor- 
mance of the responding executed object throws an exception, processing transfers from exception test step 
6804 to continue test step 6808. In continue test step 6806, the exception thrown by performance of the re- 

so spending executed object in step 6802 is compared to internal exception "continue". 

Internal exceptions "continue" and "break" are thrown by execution of selectors "continue" and "break", 
respectwely, which are discussed more completely below and in Appendix A. These exceptions are called "in- 
ternal" because internal exceptions "continue" and "break" are detected by an engine which takes actton in 
response thereto. A third internal exception, i.e., internal exception "succeed" which is thrown as a result of 

55 executing selector "succeed", is discussed below. Internal exceptions are not caught by operation "catch" and 
do not cause operation "live" to fail, thereby causing destruction of a process, except as described below. 

If the exceptmn thrown by performing the executed object in step 6802 is internal exception "continue", 
processing transfers from continue test step 6806 to step 6802 in which the responding executed object is per- 
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formed again. Otherwise, if the exception thrown in not internal exception "continue", processing transfers 
from continue test step 6806 to break test step 6808. In break test step 6808, the exception thrown by per- 
forming the responding executed object is compared to the internal exception "break". If the exception thrown 
by performance of the executed object in step 6802 is internal exception "break", processing transfers from 
5 break test step 6808 to terminal step 6810 in which operation "loop" completes successfully. Otherwise, if the 
exception thrown is not internal exception "break", processing transfers from break test step 6808 to terminal 
step 6812 in which operatron "loop" fails and the exception thrown by performance of the responding executed 
object in step 6802 is thrown by operatton loop". 

Figure 69 shows a repeat frame 6902 which records the dynamic state of a performance of operation "re- 

10 peat" by executed object 6904. Repeat frame 6902 is a part of the executton state of a process (not shown). 
Repeat frame 6902 includes properties "procedure", "repetitions". "repetitionsSoFar" and "position". Executed 
object 6904 is the responder of operatton "repeat" and is property "procedure" of repeat frame 6902. Integers 
6910 and 6911 are properties "repetitionsSoFar" and "repetitions", respectwely, of repeat frame 6902. Integer 
6910 represents the number of completed iterative performances of executed object 6906. and integer 6911 

15 represents the total number of iterath^e performances specified by the consumed integer argument 

Logic flow diagram 7000 (Figure 70) shows the implementation of operation "repeat" as performed by exe- 
cuted object 6904. In step 7002. integer 6910 is initialized to zero and integer 6911 is initialized to the value 
of the integer consumed as an argument Processing transfers from step 7002 to test step 7004 in which Integer 
6910 is compared to integer 6911. If integer 6910 is greater than or equal to integer 6911. processing transfere 

20 from test step 7004 to tenminal step 7018 in which operation "repeat" completes successfully. Therefore, if the 
integer consumed is non-positive, perfomnance of the operation "repear has no effect. Otherwise. If integer 
6910 is less than integer 6911, processing transfere from test step 7004 to step 7005 in which integer 6910 is 
incremented. Processing transfere from step 7005 to step 7006 in which an integer object whose value is that 
of integer 6910 is pushed on to the cunrent stack. Processing transfere from step 7006 to step 7008 in which 

25 responding executed object 6904 is perfonmed. It is up to executed object 6904 to pop the integer from the 
current stack. In other words, if performance of executed object 6904 does not pop the integer from the current 
stack, the integer remains on the current stack during performance of operation "repeat". 

Processing transfere from step 7008 to an exception test step 7010 in which the engine carrying out per- 
formance of operation "repeat" determines whether performance of responding executed object 6904 throws 

30 an exception. If no exception is thrown, processing transfere from exceptton test step 7010 to test step 7004. 
Convereely. if an exception is thrown, processing transfere from exception test step 7010 to continue test step 
7014 in which the exception is compared to internal exception "continue". If the exception thrown is internal 
exceptton "continue", processing transfers from continue test step 701 4 to test step 7004. Thus, if no exception 
is thrown in step 7008 or if the exception thrown is Internal exception "continue", processing transfere to test 

35 step 7004 in whteh integer 691 0 is again compared to integer 6911 . Thus, execution of selector "continue" pre- 
maturely terminates an iterative performance of responding executed object 6904 without affecting subse- 
quent iterative performances in performance of operation "repeaf. 

If, in continue test step 7014, the engine determines that perfomnance of responding executed object 6904 
in step 7008 throws an exceptton other than internal exception "continue", processing transfere from continue 

40 test step 7014 to break test step 7016. In break test step 7016, the exception thrown is compared to internal 
exceptton "break". If the exception thrown is internal exceptton "break", processing transfere from break test 
step 7016 to tonminal step 7018. In terminal step 7018. operatton "repeat" completes successfully. Thus, exe- 
cution of selector "break" terminates an iterative performance of responding executed object 6904 and suc- 
cessfully terminates perfonmance of operatton "repeat", aborting any remaining subsequent iterative perfor- 

45 mances in performance of operatton "repeat". 

If the exception thrown is not internal exception "break", processing transfere from break test step 7016 
to terminal step 7020. In tenminal step 7020. the exceptton thrown by performance of responding executed ob- 
ject 6904 is thrown by operatton "repeat* causing operatton "repeat" to fail and to propagate the exceptton. As 
discussed above, operation "catch" can be used to prevent the propagatton of the exceptton. 

so Once integer 691 0 is decremented in step 7005 to a value less than or equal to zero, processing transfere 
from test step 7004 to terminal step 7018 in which operation "repear completes successfully. Performance of 
operation "repeat" by an executed object produces no results other than those resulting from performance of 
the executed object in step 7008 of Figure 70. 

Executton of selector "continue" throws internal exception "continue" which is caught by operatfons "while", 

55 e.g.. in continue test step 6522 (Figure 65); "loop", e.g., in continue test step 6806 (Figure 68); and "repeat", 
e.g., in continue test step 7014 (Figure 70). The throwing of internal exception "continue" by execution of se- 
lector "continue" terminates an iterative performance of an executed object perfonning operation "while", "loop" 
or "repeat". As described more completely above, detection of internal exception "continue" during perfor- 
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mance of operation "while", "loop", or "repeaf causes a subsequent iterative performance of the responding 
procedure, e.g., in continue test steps 6522, 6806, and 7014 of Figures 65, 68, and 70, respectively. 

Execution of selector "break" throws internal exception "break" which is caught by operations "while", e.g., 
in break test step 6524 (Figure 65); "loop", e.g., in break test step 6808 (Figure 68); and "repeat", e.g., in break 
5 test step 701 6 (Figure 70). As with the throwing of internal exception "continue" discussed above, the throwing 
of internal exception "break" terminates an iterative perfbnmance of an executed object In the course of per- 
forming operation "while", "loop", or "repear. However, throwing internal exception "break" terminates perfor- 
mance of operation "while", "loop", or "repeat" rather than causing a subsequent iterative performance of the 
responding executed object 

10 Internal excepttons "continue" and "break" are distinguishable from other exceptions only in the context 
of operations "while", "loop", and "repeat". Therefore, in the context the following discussion of internal excep- 
tions "continue" and "break", operations "while", "loop", and "repear are collectively referred to herein as "the 
relevant operations". As each of the relevant operations detects and takes action in response to internal ex- 
ceptions "continue" and "break", internal exceptions "continue" and "break" are not thrown by either of the rel- 

15 evant operatk)ns as are other exceptions. Figure 71 serves as an illustrative example. 

Stack 7104 is a property of process 7102 and represents the thread of execution of process 7102. User- 
defined frame 71 06 is at the bottom of stack 71 04 and records the dynamic state of a perfomiance of operation 
"live". The remaining contents of stack 7104 from bottom to top are repeatframe 7108, predefined frame 7110, 
which records the dynamic state of a performance of operation "loop", and user-defined frame 7112. Thus, 

20 operation "live" In Figure 71 caused performance of operation "repeat" which caused performance of operation 
"loop" which caused performance of yet another feature. 

Suppose that performance of the feature, whose dynamic state is recorded by user-defined frame 7*;12, 
executes selector "continue" or selector "break". As discussed above, execution of either selector "continue" 
or "break" throws a corresponding internal exception. Any operation which is not designed to catch these in- 

25 ternai exceptions. I.e.. any operation other than either of the relevant operations, behaves as if an ordinary 
exception has been thrown (see discussion above regarding exception test step 5210 and terminal step 5212 
of Figure 52A). In this situatbn, the internal exception is propagated by performance of the feature represented 
by user-defined frame 7112 and is caught by performance of operation "loop" represented by predefined frame 
7110 In the manner discussed at)ove. The internal exception is not propagated by operation "loop" represented 

30 by loop frame 7110 and therefore has no effect on the performance of operation "repeat" represented by repeat 
frame 7108. 

If no relevant operation is cun^ntly being performed, i.e.. is not present on stack 7104, executton of either 
selector "continue" or selector "break" produces an exception of class "Loop Missing". An exception of dass 
"Loop Missing" is not an interna) exception and Is therefore propagated like any other exception. 

35 If internal exceptton "succeed" is thrown. I.e.. If selector "succeed" is executed, perfonmance of the current 
method terminates successfully. It should be noted that, since predefined features are implemented directly, 
i.e., in the computer instructtons which collectively form an engine, only user-defined features are implemented 
by method objects. Therefore, if operation "loop", the dynamic state of a performance of which is recorded in 
predefined frame 7110 (Figure 71). executes selector "succeed", an internal exception "succeed" is thrown. 

40 terminating performance of operation "loop". Since operation "loop" is predefined, operation "loop" does not 
catch internal exceptton "succeed" and therefore propagates internal exception "succeed", causing the termin- 
ation of operation "repeat", the dynamic state of a performance of which is recorded in repeatframe 7106. Slnrv 
ilarly, as operatun "repeat" is predefined, operation "repeaf does not catch internal exception "succeed", 
causing the termination of operation "live", the dynamic state of a perfonnance of which is recorded in uaer- 

45 defined frame 7106. However, since operation "live" has no predefined implementatran, operatnn "live" ter- 
minates successfully, i.e., does not fail by throwing an exception. Similarly, if the feature whose method is 
the subject of user-defined frame 7112 throws internal exception "succeed", i.e., executes selector "succeed", 
the feature terminates successfully and internal exceptk>n "succeed" is caught In such a case, internal ex- 
ception "succeed" has no effect on predefined frame 7110. repeatframe 7108. and user-defined frame 7106. 

50 The operations discussed above, i.e.. operations "do", "if", "either", "while", "select", "catch", "loop", and 
"repeat" are performed in the context of the current method. As discussed above, predefined operations are 
not implemented by method objects. The above-listed operations are all predefined and are therefore not im- 
plemented by method objects. The performance of the above-listed operations in the context of the current 
method is easily described by way of example. 

55 Suppose, for example, that the feature whose method is the subject of frame 7112 (Figure 71) requests 

performance of one of the above-listed predefined operations, the perfomnance of which is recorded in a pre- 
defined frame (not shown) immediately above user-defined frame 7112 on stack 7104. During performance 
of the predefined operation, property "stack" of user-defined frame 7112 remains "the current stack." Thus, 
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the current method. Predefined operations listed above are performed In the context of 
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1 INTRODUrriQN 

The three major elements of the Telescript technology 
are introduced in this section of this appendix: the 
10 Telescript Instruction Set, i.e. the subject of this 
appendix; the Telescript Engine, which implements the 
20 Instruction Set; and the Telescript Network, formed by 

interconnecting Engines, 



1-i Telescript Insti-u(;;^,inri 
15 The Telescript Instruction Set, which is sometimes 

referred to herein as the "Instruction Set", is a set of 
computer instructions vrhich collectively form a 
programming language whose intended field of application 
is distributed systems and applications. The Instruction 
20 Set is both object-oriented and interpreted. In 

Microfiche Appendices E and F, the Instruction Set is 
sometimes referred to as "the Language". 

The most distinctive classes built into the 
Instruction Set are classes "Agent" and "Place". An 
25 agent, i.e. a computer process that is a member of class 
^ "Agent", is an active object that can examine and modify 

itself, transport itself from one place in a network to 
another, and interact with the other agents it finds 
^ there. This power is counterbalanced by permits, which 

30 enable either a programmer or an administrator to grant 
only particular capabilities to particular agents on 
particular occasions. A place, i.e. a computer process 
that is a member of class "Place", is an active object 
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that can examine and modify itself and that serves as a 
venue for agents and a context in which they can interact. 

An agent goes to a place and there interacts with the 
place and other occupants of the place. Agents and places 
5 cannot interact at a distance. Thus the Instruction Set 
implements remote programming (RP) , not the more familiar 
remote procedure calling (RPC) paradigm. RP improves upon 
RPC by enabling system elements to interact without 
communicating, improving the performance of the 
10 interactions by reducing their latency. Equivalently, RP 
enables system elements to customize one another by 
stationing their own agents --and thus themselves --in one 
another's domain. 

The Instruction Set strives to achieve these 
15 characteristics: 
Safety - 

• The Instruction Set prevents a process from exceeding 
its permit, interfering with another process without 
the latter' s permission, or directly manipulating the 

20 computer on which the process runs. This helps to 

avoid viruses. 
P9yt»]?a,j,j,t;y 

• The Instruction Set makes no concessions to the 
hardware or software constraints or peculiarities of 

25 a particular computer system. This enables a process 

to be executed anywhere within or around a network. 
Extendibilit^Y 

• The Instruction Set gives to types of information 
object defined by the programmer the same stature as 

30 those built into the Instruction Set. This enables 

extension of the Instruction Set for particular 
purposes . 
Elevai^ion 

• The Instruction Set draws no distinction between 

35 volatile and non- volatile storage. Every information 

object is inherently persistent. This increases a 
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process level of abstraction and decreases the 
process' size. 

1-2 Telescrint Enqing 

A program written in the Instruction Set is brought 
5 to life by a Telescript Engine, which is sometimes 

referred to herein as an "Engine", which interprets the 
instructions the program contains. Such a program is 
called a telescript. One Engine can interpret many 
telescripts concurrently. 
10 An Engine can implement the abstractions of the 

Instruction Set without directly relying upon the hardware 
^ or operating system of the computer on which the Engine 

runs. The Engine does this using standard interfaces to 
the communication, storage, and other subsystems the 
15 Engine requires of the platform. These form the 
25 Telescript Communication Application Programming Interface 

(API) which is attached as Appendix C and is a part of 
this disclosure and is incorporated herein in its entirety 
by reference, 

30 

20 An Engine can implement privileged escapes from the 

abstractions of the Instruction Set. Such escapes enable 
the construction, external to the Engine, of operational, 
35 administrative, and managerial (OAMJ tools. Such tools 

are vital to the success of large-scale communication 
25 systems. 
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1.3 Telescrint Network- 

Two or more Engines can be interconnected. The 
resulting Telescript Network, which is herein sometimes 
called the "Network- is the universe within which agents 
30 travel. The Network encompasses computer systems that 
would be considered clients of other networks, not parts 
of them. 

A computer system is a part of the Network only if 
the system incorporates an Engine and thus provides places 
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from and to which agents can go. This requirement makes 
the Network homogeneous with respect to the structure, as 
well as the transport, of information. 

Engines are interconnected so that they can move 
5 agents among themselves. Agents are serialized, or 
encoded, for this purpose according to the Telescript 
Encoding Rules described in Appendix B. The resulting 
octet string is transported between Engines as prescribed 
by the Platform Interconnect Protocol which is attached ai 
10 Appendix F as a part of this disclosure and is 
incorporated herein in its entirety by reference. 

1.4 This Appendix 

This appendix is described as follows. 

1-4.1 Scope 

15 This appendix defines Version 0.8 of the Instruction 

Set. The Telescript Encoding Rules, the Telescript 
Protocol, and the Telescript API are all beyond the scope 
of this appendix and are the subject of respective 
Appendices B, F, and C. 

20 One may view the Instruction Set as an instruction 

set for a virtual machine. From this viewpoint, one can 
readily envision still higher-level languages, compilers 
for which produce telescripts. General Magic Inc. of 
Mountain View, California is developing such a language 
25 which is called High Telescript. In the context of 
Appendices A-F of this disclosure, the Instruction Set 
itself is sometimes called Low Telescript. 

1.4.2 Conformani^g 

A manufacturer of an Engine has to satisfy certain 
3 0 requirements to properly claim conformance to this 
appendix, 

1.4.3 Convent inns 
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These conventions of prose are followed throughout 
this appendix: 

• "The a attribute" means "the attribute whose 
identifier equals a" . 

5 • "Is a key" means "equals a key", and not "is the same 
as a key" . 

• "An 25" generally means "a member of X"/ and not "an 
instance of JJ" • 

• "Throws 2£" generally means "throws a member of X". 
10 • "Whether statement " means " statement iff true " . 

• Iff means "if and only if", as it does in 
mathematics. 

• MSB stands for "most significant bit". 

• LSB stands for "least significant bit", 

15 Hatfi: Throughout this appendix, notes {like this) are 

explanatory, not definitive. 

1*4.4 Organization 

This appendix is divided into eight sections. 
Section 1 is this introduction. Section 2 introduces the 
20 Instruction Set's major concepts. Section 3 overviews the 
Instruction Set's predefined classes. Section 4 defines 
them in detail. Section 5 defines the Instruction Set's 
syntax . 

Section 6 defines the conventions followed by the 
25 formal definitions of the interfaces to the predefined 
classes. Section 7 comprises those formal definitions. 
Section 8 shows the part of the class graph that comprises 
the predefined classes and no user-defined classes. 

1.4.5 Road Map 

30 Parts of this appendix are definitive, while others 

are merely informative. The definitive sections are 
Sections 1, 2, 4, and 5, In contrast. Sections 3, 7 and 
8, reorganize material in Section 4, while Section 6 
duplicates aspects of High Telescript. 
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Different audiences require different parts of this 
appendix. Those interested only in the Instruction Set's 
scope and structure need read only Sections 1, 2, and 3. 
A Telescript programmer requires Section 4 as well. A Low 
5 Telescript programmer must master also the portion of 
section 5 covering character telescripts, while the High 
Telescript programmer need not do so. A High Telescript 
Compiler or Engine implementor requires the portion of 
Section 5 covering binary telescripts. 

For Telescript practitioners. Sections 7 and 8 are 
indispensable references. 

1.4.S fief^y^ncea 

This appendix relies upon these other documents: 

In^Qym^tion technolQav- -Unive r sal Cr>H^r^ Character fi^ ^ 
iiZCSI, ISO/IEC DIS 10646, International Organization 
for Standardization and. International 
Electrotechnical Commission, 1990, 

[Unicode] 

20 Th^ ^n^C9<ag Standard: Worldwidf. rh a racter Knnr^r^i^r^ 

Volume 1, Version 1.0, The Unicode Consortium, 
Addison- Wesley, 1991. 

2 TELESCRIPT CONCEPTS 

The Instruction Set defines a variety of concepts, 

25 the most important of which are introduced in this section 
of this appendix. These concepts are divided into 
"models". A subsection is devoted to each model. Within 
each subsection, a lesser subsection is devoted to each 
concept in the model. 

30 Being for remote programming, the Instruction Set 

includes concepts spanning the realms of languages, 
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operating systems, and networks. Conventionally separate, 
these areas, in this instruction set are brought together. 

2.1 Models 

The Instruction Set's concepts are divided into 
5 models. This division serves pedagogic purposes alone and 
is not visible, in any sense, at run time. 
The following models are defined: 

The "Object" model provides object orientation, e.g., 
10 objects, references, classes, operations, and exceptions. 

The "Execution" model provides sequential execution, 
e.g. methods, procedures, and identifiers. 

Process 

15 The "Process" model provides mult i- tasking, e.g., 

processes, resources, permits, contacts, and ownership. 



yetWQds 

The "Network" model provides network architecture, 
35 e.g., agents, places, trips, meetings, and telenaraes. 

20 Timekeeping 

The "Timekeeping" model provides means for keeping 
40 time, e.g., times and calendar times. 

Pattern Matching 

The "Pattern Matching" model provides means for 
^ 25 pattern matching, e.g., patterns. 

The models are presented below in the order in which 
^ they are listed above. The concepts within each model are 

presented in a logical order. 
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2.2 Object Model 

The Instruction Set realizes the "object model" this 
section defines. 

2.2,1 Object? 
5 An object is the Instruction Set's unit of both 

information and information processing. An object is an 
instance of a class. 

Note: An object may be anything at all, either simple, 

e.g., a boolean, or complex, e.g., a dictionary, 
either passive, e.g., a string, or active, e.g.. 



10 



20 a process. 

HQt£: In messaging, the application for which the 

Instruction Set was conceived, the objects can 
include the messaging system's component parts, 
15 e.g., its mailboxes and distribution lists; the 

information objects the system transfers, e.g., 
messages and delivery reports; and the elements 
of those information objects, e.g., the fields 
of envelopes. 

35 20 Persistency 

Every object is "persistent". If the Engine fails 
and subsequently recovers, the only effect upon the object 
is its temporary unavailability. 

40 ^ 

25 Every object has a "size" which is the approximate 

4S amount of persistent storage the object occupies, measured 

in octets. 

Hatft: An object's size may vary from place to place. 
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A "reference" is the means by which an object is 
denoted and accessed. 



Protected vgU nprotected 

A reference is either "unprotected" or "protected". 
5 An unprotected reference enables the object to be changed, 
while a protected reference does not. An unprotected 
reference can be made protected, but not conversely. 

There exists one or more references to every object. 
10 Creating an object creates an initial reference to the 
object as well. The reference is protected iff the object 
is immutable. Additional references can be created as 
desired^ Created references are protected iff the source 
reference is protected. 

15 Many predefined operations create new references 

to existing objects and return the references as 
results. 



Comparison 

All unprotected references to an object are 
20 equivalent. Changes made using an unprotected reference 
to an object are made to the object, and thus, in effect, 
to all other references to the object. All protected 
references to an object also are equivalent to one 
another. 

25 An unprotected and a protected reference differ in 

two ways which come to light when a protected reference is 
used to request a feature of the object the reference 
denotes. First, if the feature would change the object, 
the feature fails, throwing "Reference Protected". 

30 second, if the feature returns a reference to— not a copy 
of- -one of the object's properties, that reference is 
protected. 
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One can determine whether two references denote the 
same object. 

Discarding 

A reference should be discarded when no longer 
5 needed. If no references to the same object remain, the 
object itself is destroyed. 

The Engine voids references under circumstances this 
appendix defines. A "voided" reference no longer provides 
10 access to an object. The Engine throws "Reference Void" 
rather than push a voided reference onto the stack. 

2.2.3 ciagggg 

A "class" defines a set of objects, the class' 
"instances", all having the same interface and the same 
15 implementation. The class itself has both an interface 
and an implementation, which are potentially unique to the 
class . 

Predefined vs TTfl er-def ini:> j 

A class is either predefined or user-defined. A 
20 "predefined" class, built into the Instruction Set and 
defined in this appendix, represents a kind of object 
available to every Telescript programmer. A 
"user-defined" class, defined by the programmer, extends 
the Instruction Set for specific purposes. 

25 Concrete VS Abfitirar;;^ 

A class is either concrete or abstract. A "concrete" 
class can have instances. An "abstract" class cannot, but 
its subclasses can and often do. A concrete class, or one 
of its implementation superclasses, shall implement each 

30 feature either native to or inherited by the class. 
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A class, usually concrete, can be sealed. The Engine 
prevents a sealed class from having user-defined, but not 
predefined, immediate subclasses. 

5 Creation 

A concrete class can create a new instance given 
initialization parameters describing the new instance. 
Not every instance of every class, however, can be created 
in this way. The remaining ones can be created by first 
10 creating one instance in this way and then modifying the 
instance's attributes as necessary. 

Converaion 

A concrete class can convert an instance of one class 
to an instance of itself. Not every instance of every 
15 class, however, can be converted to an instance of every 
: other class. The definition of operation "convert", and 
the nature of the object conversion produces, depend upon 
the two classes involved. 

Compatibility 

20 A class is embodied as a cited object. One class is 

backward compatible with another iff the former's 
interface can be created from the latter' s by making only 
changes of the following kinds. First, a feature can be 
added. Second, if in the latter' s interface an attribute 

25 is read-only, that attribute's class can be narrowed to a 
subclass. Third, the class of an argument of an existing 
operation can be widened to a superclass. Fourth, the 
class of the result of an existing operation can be 
narrowed to a subclass. 

30 2.2.4 Inheritaq rf> 
Native vs Tn^^ri,<-**<t 
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All Classes, both predefined and user-defined, are 
related to one another by "inheritance". Every class has 
various characteristics. In general, some of a class' 
characteristics are "native" to the class, while others 
5 are "inherited" from other classes. Inheritance is a 
transitive relationship. A class inherits from a class 
the latter 's inherited characteristics, as well as the 
latter' s native characteristics. Extending the above 
terminology only slightly, an object's native 
10 characteristics are those native to the class of which the 
object is an instance. 

The Instruction Set sufficiently constrains the 
inheritance relationships among classes that the classes 
and their relationships can be described by simple graphs. 
15 In such a graph, the nodes represent classes, the arcs 
between nodes the inheritance relationship between the 
classes the nodes represent , 

Subclass yg Superclass 

If one class inherits characteristics from another, 

2 0 either directly or indirectly, the former is a "subclass" 
of the latter, and the latter is a "superclass" of the 
former. If one class inherits characteristics from 
another directly, the former is an "immediate subclass" of 
the latter, and the latter is an "immediate superclass" of 

25 the former. 

An instance of a class is a "member" of that class 
and of its superclasses . 

Flavor 

Some classes are flavors. The "flavors", each of 
30 which is either abstract or concrete, form a tree as 

follows. The tree's root represents class "Object". Each 
destination node reached by an arc emanating from any 
given source node represents an immediate subclass of the 
flavor that the source node represents. Thus the source 
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node represents an immediate superclass of the flavor 
5 represented by each such destination node. Each 

destination node reached by way of one or more arcs in 
succession represents a subclass of the flavor that the 
5 source node represents. Thus the source node represents a 

10 

superclass of the flavor represented by each such 
destination node. 

Note : Flavors provide single inheritance. 

15 

Mix-in 

10 All other classes are mix-ins. A "mix-in" and its 

zero or more superclasses- -all mix-ins themselves- -form a 
second tree as follows. The tree's root is the mix-in. 
The arcs represent the inverse inheritance relationship 
between the mix-ins that the tree's nodes represent. A 

15 mix-in is abstract. 

25 

Note : Mix-ins provide a limited form of multiple 

inheritance * 

30 Class Graph 

The flavors and mix-ins together form a directed 
20 graph. The graph is constructed in the following two 

steps. First, the arcs in each mix-in tree are reoriented 

35 

to represent the inheritance relationship, rather than its 
inverse. Second, the thusly altered mix-in trees are 
superposed upon the flavors tree. 
40 25 Note : There is one, global class graph, achieved by 

identifying classes globally. In any particular 
place, knowledge of the graph may be incomplete. 

^ Canonical Order 

A class, either a flavor or a mix-in, and its 
30 superclasses, both flavors and mix-ins, have a "canonical 
order" which is that of a walk of a third tree. 

50 

The tree is formed as follows. Its root is the class 
in question, its other nodes the class' superclasses. As 
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in a mix-in tree, the arcs represent the inverse 
inheritance relationship among the classes that the tree's 
nodes represent. 

The walk is a depth- first one in which a class' 
5 immediate superclasses are visited in their canonical 
order, which the class defines. 

Interface vg Imnl^menta&tQn 

All of the above can be said about either of three 
sets of class characteristics: the classes' interfaces, 
10 their implementations, or both. This appendix explains, 
either explicitly or implicitly, which of the two sets of 
characteristics is being discussed at any particular point 
within this appendix. 

Nats: More often than not, the classes' interfaces are 

15 in view. 

2.2.5 F^^tyyeg. 

A "feature" is an externally visible characteristic 
of an object. Features enable objects to interact. If 
one object possesses a reference to another, the former 
20 can request a feature of the latter. All instances of a 
class have the same features, defined by the interfaces 
native to or inherited by that class. 

A feature "succeeds", when it is used correctly, and 
"fails", at other times, when the feature fails, an 
25 exception is thrown. 

Attribute vg QoG^ra^in^ 

Features are of two kinds, attribute and operation. 
Sifite: Whether a particular feature is made an 

attribute or an operation is, in part, a matter 
30 of taste. 

Scaling 
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A class can seal a feature, either native or 
inherited, thereby preventing the feature's implementation 
by user-defined, but not predefined, subclasses, 

Implement;at;ion 
5 A class can implement any native feature or any 

inherited feature not sealed by a superclass. In the 
latter case, the class' implementation supersedes the 
superclasses' implementations, if there are any. 
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The Engine controls access to a feature. A feature's 
"access" defines the objects that can use the feature, and 
is one of the following: 

public 

Any object can use the feature. 



15 prAv^tg 

^ Only the object that has the feature can use it. 

Only the Engine itself can use the feature, which is 
predefined. 



20 2.2.6 Attributfifl 

An "attribute", an object, is any characteristic that 
one object, the -requester", can ask another or the same 
object, the "responder", to get and perhaps set. An 
attribute that cannot be set is "read-only". 



25 "aGet" v g "fys^^ ;>t 

An attribute is exactly equivalent to either one 
operation, if the attribute is read-only, or two, 
^ otherwise. The first operation, denoted symbolically as 

"aGet% gets the attribute. It has no arguments, and its 
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result is the attribute. The second operation, denoted as 
"aSet" replaces the attribute with a particular object. 
The one argument of operation "aSet" is that object, and 
the operation has no result. 

5 Manual vs Aut:nma^^^ 

A class can implement an attribute either manually, 
automatically, or. iff the class is abstract, not at all. 
To "manually" implement an attribute is to provide methods 
for "aGef and, if the attribute can be set, "aSet". To 
10 "automatically" implement an attribute is to let the 
Engine do so, which it does if the attribute is an 
instance attribute, the class is concrete, and neither the 
class nor its implementation superclasses implement the 
attribute. The Engine implements the attribute with a 
15 property of the same identifier . 

The Instruction Set defines the getting and setting 
of attributes with the aid of "getAttribute" and 
-setAttribute", respectively, internal operations an 
argument of which is the attribute's identifier ("a"). 
20 These two operations get and set, respectively, the 

property associated with the attribute, if the latter is 
implemented automatically, or perform the user-defined 
methods for operations "oGet" and "aset", otherwise, i.e., 
if the attribute is implemented manually. An attribute's' 
25 manual or automatic implementation alike is located using 
the execution model's algorithm for locating the 
implementation of an operation. 

An attribute that is not read-only behaves by default 
30 as a "storage location". That is, operation "oGet- 

returns the object most recently supplied successfully as 
an argument of operation "aSet". Exceptions to this 
default behavior shall be called out in the prose 
descriptions of particular attributes. 
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Nets: Thus if an attribute exhibiting the default 

behavior is constrained to be a member of class 
"Dictionaiy", and an instance of a subclass of 
class "Dictionary" is supplied to operation 
5 "aSet", operation "aGet" returns that instance 

of that class, not an instance of class 
"Dictionary" . 

Hats: All predefined attributes which are read-only 

exhibit the default behavior. 

10 2.2,7 Qp^r^tj^Qng 

An operation is any task that one object, i.e. "the 
requester", may ask another or the same object, i.e. "the 
responder", to perform. 

15 The requester supplies the responder with zero or 

more objects, which are the operation's "arguments". An 
operation defines whether the operation's arguments are 
variable or fixed in number and, if the latter, how each 
is constrained. 
20 UQLS,- If the arguments are variable in number, none 

may be a mark. 
Notfe: Of the predefined operations, operations 

"initialize", "makeClasses" , "select" and "new", 
and no others require a variable number of 
25 arguments. 

The responder can optionally supply the requester 
with a single object, the operation's "result", if the 
operation succeeds. An operation defines whether there is 
30 a result and, if so, how it is constrained. 

2.2.8 Except; jp^js 
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An "exception" is an object describing the failure of 
either the performance of a method for a feature or, more 
fundamentally, the execution of one of the executed 
objects that are the items in the method's procedure, 

A feature fails when its responder "throws" an 
exception in lieu of any result the responder would have 
returned had the feature succeeded. The feature's 
requester "catches" the exception if the requester wishes 
to react to the exception. Otherwise, the Engine 
"propagates" the exception, i.e., causes the requester to 
throw the except ion . 



2.2.9 Constraint^ 

A "constraint" defines restrictions that are placed 
upon other objects, which are the constraint's "sxibjects", 

15 The possible restrictions include the identifier of the 
class of which the subjects shall be members, that class 
itself, whether the subjects shall be instances of that 
class, whether the subjects are permitted to be nils, the 
class just mentioned notwithstanding, and the subjects' 

20 passage. 

Passage 

An object may be passed between a feature's requester 
and responder in any of several different ways, which 
determine how the source reference, which the object's 
25 source conveys to the Engine, determines the destination 
reference, which the Engine conveys to the object's 
destination. 

An object's "passage" is one of these identifiers: 



30 



bvRef 

The destination reference is the source reference. 
bvannrofectedR^f 
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The destination reference is the source reference, 
but the Engine throws "Reference Protected" if the source 
reference is protected. 

bvProtectedR^.f 

5 The destination reference is a protected reference to 

the object to which the source reference provides access. 

. The destination reference is an unprotected reference 
to a copy of the object to which the source reference 
10 provides access. The Engine makes the copy for this 

purpose alone. The copy is owned by either the object's 
destination, if a process, or the object's destination's 
owner, otherwise. 

2.2.10 Properties 

15 An object has zero or more properties. Itself an 

object, a "property" is one element of the object's 
internal state, all of the object's properties, taken 
together, constituting the entire internal state. An 
object's properties are internal to it, and thus can be 

20 directly sensed, examined, and modified by that object 
alone . 

An object's properties are partitioned by class. 
Zero or more are native to the object's class, and zero or 
more to each of the class' implementation superclasses. 
25 A property can be directly sensed, examined, and 

modified by the methods of the class to which the property 
is native, but not by the methods native to other classes, 
not even the class' subclasses or superclasses. 



30 



2.2.11 Copying 

Objects can be copied. A "copy" of one object is 
another object that is indistinguishable from the former 
object except, in general, by means of operation "isSame" 
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and by the fact that the copy can be changed, even if a 
protected reference was used to create the copy. 

A copy generally equals the original from which it 
was fashioned, at least initially. The meaning of "equal" 
5 depends upon the classes of which the original is a 
member. If the class, and thus the copy, are immutable, 
the copy and original remain equal indefinitely. 
Otherwise, they can diverge, as the copy and the original 
are independent. 

10 A copy is created using operation "copy". The Engine 

creates the copy by requesting operation "copy" of each 
property of the original. However, if the Engine finds a 
property to be a reference to an object the Engine has 
copied for this purpose already, the Engine does not make 

15 a second copy of that object, but rather uses a reference 
to the first, 

2.2.12 9frigc<: xnlrtaliz^r.iPTi 

An object's creation entails the object's 
initialization. A method for operation "initialize" can 
20 be native to any class of which the created object is a 
member. The method shall initialize the object's 
properties native to that class. 

Before the Engine requests a method for operation 
"initialize", it sets to nils the properties that are 
25 native to the class to which that method is itself native. 



Initialization Order 

Each method for operation "initialize" shall escalate 
the operation after initializing the properties for which 
4S the method is responsible, thereby allowing other methods 

30 to do the same. If a method succeeds without escalating 
the operation, the Engine does so for the method. The 
process of escalation visits the class of the created 
object and that class' implementation superclasses in 
canonical order. 
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InitializationPa rametera 

A class' "initialization parameters" are the objects 
that the method for operation "initialize" native to that 
class requires for the operation's performance. If the 
5 class is a mix-in, it speaks, by its choice of parameters, 
for itself alone. If the class is a flavor, it speaks for 
itself and its implementation superclasses alike. At 
escalation, a class' method for operation "initialize" 
shall have ensured that the parameters of the classes yet 
10 to follow in the canonical order are on the stack, above 
the topmost mark. After the methods for all classes have 
been performed, class "Object" throws an exception if any 
parameters remain. 

Initialization Privilegeg 

15 A method for operation "initialize" can use a feature 

of the created object after escalation but not before. 
Even then, the object responds as if it were an instance 
of the class to which the method is native, not the class 
of which the object is an instance. The method can use 

20 other objects' features at any time. 

2.2.13 Object Finalization 

An object's destruction entails the object's 
f inalization. A method for operation "finalize" can be 
native to any class of which the destroyed object is a 

25 member. The method shall finalize the object's properties 
native to that class, 

A method for operation "finalize" can optionally 
discard, and thus perhaps destroy, the properties the 
operation finalizes. If the method does not do so, the 

30 Engine does. 

Finalization Order 

A method for operation "finalize" does not escalate 
the operation. The Engine performs each method whether or 
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not other methods succeed, visiting the class of the 
destroyed object and its implementation superclasses in 
canonical order. 

2-2.14 Class Construction 
5 The Instruction Set, unlike many computer languages, 

enables classes to be created at run time via operation 
"makeClasses" , A class is created on the basis of a class 
definition which defines both the class' interface and the 
class' implementation. 

10 Identifier Bindings 

A class' interface or implementation typically 
depends upon other classes which the interface or 
implementation denotes by identifiers. A citation is 
bound to each such identifier with the aid of the 

15 interface's or Implementation's "vocabulary" attribute. 

If the identifier equals that of a predefined class, 
the citation is to that class. Otherwise, if the 
identifier equals a key in the "vocabulary" attribute, the 
citation equals the associated value. Otherwise, the 

20 citation equals that of the constructed class, except that 
the citation's "title" attribute equals the class' 
identifier. 

lifitS: The Instruction Set does not define the 

predefined classes' assigned citations. 

25 Citation Bindings 

A class is bound to a citation with the aid of the 
"privateClasses" and "publicClasses" attributes of the 
current process and the current place, respectively. 

If a cited class is predefined, the cited class is 
30 found in the Engine itself. If it is user-defined, the 
class is sought, and may or may not be found, in the 
"privatBClasses" attribute of the current process, and, 
failing that, in the "publicClasses" attribute of the 
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current place, the class being any that is backward 
compatible with the cited class. 

A class is bound to the citation at one of two times. 
If the class' identifier is an item of a procedure, the 
5 class is sought whenever the identifier is executed. 
Otherwise, the class is sought when the class is 
constructed. 



2,3r Execution MnH^I 

The Instruction Set realizes the "execution model « 
10 this section defines. 

2.3.1 Methods 

A "method" is a procedure which is able to separately 
maintain the dynamic state of each of its performances. 
That dynamic state takes the form of a frame. Methods are 
15 used to implement operations, conversions, and selected 
attributes , 

Frame 

A "frame" comprises a stack and zero or more 
variables. Itself an object, a "variable" is one element 

20 of the dynamic state of a particular performance of the 
frame's method, all of the frame's properties, taken 
together and with the stack, constituting the entire 
dynamic state. A frame's stack and variables are internal 
to the frame, and thus can be directly sensed, examined, 

25 and modified by the frame's method alone. The frame 
itself cannot be manipulated at all. 

To "perform" a method is to create a frame, accept an 
offer of objects as the initial items of the frame's 
30 stack, set the frame's variables to nils, perform the 
method's procedure, discard the frame, and, iff the 
procedure succeeded, offer the final items of the frame's 
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stack, having popped them from that stack before 
discarding the frame. The method's performance succeeds 
or fails if the procedure succeeds or fails, respectively. 
At any point in time, the "current method" is the 
5 method currently being performed, the "current frame" is 
the frame created for that performance, and the "current 
stack", i.e. "the stack", is that of the current frame. 
yptS : If the method implements an operation, the 

objects offered as the initial items of the 
stack are the arguments, the topmost of the 
objects offered as the final items the result, 
if there is one. In between these two events, 
the stack holds first the arguments and then the 
result, if there is one, of any operation the 
method requests. Items other than the topmost 
item of the stack at completion of the 
operation, if there are any, are objects used 
during performance of the operation to carry out 
intermediate steps of the operation. 

20 2.3.2 Procedures 

A "procedure" comprises zero or more executed 
objects, its "items", which are not among the procedure's 
properties, but rather are more fundamentally a part of 
the procedure. The items are numbered in the range [1, 

25 n] , "n" being the procedure's "length". The procedure is 
"cleared" if its length is zero. An item's number is its 
"position" in the procedure. A "subprocedure" comprises 
zero or more items in adjacent positions within a 
procedure . 

30 Performance 

To "perform" a procedure is to execute its items 
sequentially, in order of increasing position, in the 
current frame. The procedure's performance either 
"succeeds", if each item is executed successfully, or 
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"fails", otherwise. If the execution of any item fails, 
no remaining item is executed. 

2.3.3 Executed OhiPft^ 

An "executed" object is permitted as an item of a 
5 procedure . 

Performannf> 

To "perform" an executed object other than a 
procedure is to execute it. 



Execution 

10 To "execute" an executed object is to do things that 

depend upon whether the executed object is an identifier, 
a modifier, a selector, or something else. Execution 
either "fails", if the Engine throws an exception, or 
"succeeds", otherwise. 
15 Any executed object other than an identifier, a 

modifier, or a selector is executed by pushing onto the 
stack a protected reference to the executed object. 
Hq£s: The executed objects in question in the 

preceding paragraph are bits, bit strings, 
booleans, characters, integers, marks, octets, 
octet strings, procedures, reals, and strings. 



20 



2^3.4 Identifiers 
^ A particular class, feature, property, or variable is 

denoted by an identifier, as are other constructs and 
25 objects in the Instruction Set. 

45 

Identifier 

An "identifier" distinguishes one object from others 
within its scope by means of the identifier's "text", a 
string whose length is at least one. 



30 Qualified Identifipr 
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A "qualified identifier" distinguishes zero or more 
implementations of a feature from zero or more other 
implementations of the same feature. A qualified 
identifier denotes the feature by means of the text of its 
5 identifier. It denotes the implementations- -those either 
native to or inherited by a class --by means of the text of 
the class' identifier, which is the qualified identifier's 
"qualifier" . 

Scope 

10 No two identifiers having the same scope shall be 

equal . 

A class cited by an interface or an implementatioa is 
denoted by an identifier whose scope is all classes cited 
15 by that interface or implementation. 

Feature 

A feature of an object is denoted by an identifier 
whose scope is all features whether native to or inherited 
by the class of which the object is an instance. 

35 20 Pr9Pgr?;y 

A property of an object is denoted by an identifier 
whose scope is all properties native to the class to which 
the property in question is itself native. 
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Variable 

25 A variable of a frame is denoted by an identifier 

whose scope is all variables defined by the method to 
whose performance the frame pertains. 
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5 

A text or a qualifier shall exclude the characters 
Table A.l. 



10 













Characters 


Notes 


5 

IS 


Control Characters 










U+0000 U+OOIF 


As in ASCII. 


20 




U+007F -- U+009F 


As above, but with 
Bit 7 one. 




Soacea 


Various 


See [Unicode] §4.2, 
U+0020, U+OOAO, 
etc. 


25 


Symbols and 
Punctuation 


U+0021 U+002F 


As in ASCII. 






U+003A U+0040 


As in ASCII. 


30 




U+005B U+005E 


As in ASCII. 






17+0060 


As in ASCII. 


35 




U-f007B U+007F 


As in ASCII. 






U+OOAl U-fOOBF 


In Latinl. 


40 




U+00D7 & U+O0F7 


Multiplication 
("X") and division 
(+) signs 






U+2000 -- U+2FFF 


Assigned symbols . 


45 

10 


Private Us*^ 


U+E800 -- U+FDFF 






Soecial Characters 


U+FFFO -- U+FFFD 





so 
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The first character of a text or a qualifier shall 
exclude the characters in Table A. 2, as well as those i; 
Table A.l. 



20 



TABLE A.;? 




Characters 


Notes 


Decimal Diaite 


Various 


See [Unicode] §4.1. 
U+0030-- U+0039, 
etc. 


Non-9Mcina Marks 


Various 


See [Unicode] §4.5. 





fiOtfi: When one programs in High Teleacript, the 

privilege of assigning identifiers the first 
25 character of whose text is an underscore 

(U+OOSF) is reserved for the High Telescript 
Compiler itself. 

30 2.3.5 Static Substitution Pm^ff 

A procedure is performed as if the substitutions in 
Table A. 3 below had been made, wherever a subprocedure in 
15 the first column appears in the procedure, the 
35 subprocedure in the same row of the second column replaces 

it. 

Table A. 3 defines each subprocedure using the 
non-terminals used to define telescripts. In the table's 
40 20 first section, "Identifier" stands for either itself or 

"Qldentif ler- , in the second section, "Identifier" stands 
for itself alone. 
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TABLE Ari? 


Subprocedure 


Substituted Subprocedure 


SetAttribute Identifier 


Mention Identifier Swap 
"SetAttribute" 


UseStack Identifier 


UseStack Identifier*-^ 






GetClass Identifier 


Mention Identifier Self 
"getClass" 


GetProperty Identifier 


Mention Identifier Self 
"get Property" 


GetVariable Identifier 


Mention Identifier Self 
"getVariable- 


SetProperty Identifier 


Mention Identifier Self 
"set Property" 


Setvariable Identifier 


Mention Identifier Self 
"setvariable" 


Mention ExecutedOb j ect 


Mention "ExecutedObject^" 



^This substitution applies iff the identifier is neither 
that of operation "protect" nor opeation "ref". 

^This substitution is an identity. 

If asked to create a procedure having modifiers 
15 arranged in subprocedures other than those in Table A. 3 or 
Table A. 4 below, the Engine throws an exception. 

An internal operation, discussed in Section 3.2.12 of 
this appendix, succeeds only if requested as the result of 
one of the substitutions in Table A. 3 or Table A. 4. An 
20 internal operation is otherwise inaccessible. 
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2.3.6 Dynamic Substitufcion Pu\a^ 

A procedure is performed as if the substitutions in 
Table A. 4 had been made as well. In Table A. 4, 
"Identifier" stands for either itself or "Qldentif ier" . 



TABLE A. 4 


Subprocedure 


Substituted Subprocedure 


Identifier 


Mention Identifier Swap 
"get At tribute"* 


Demarcate Identifier 


Mention Identifier Swap 
Demarcate "getAttribute"' 


Demarcate Identifier 


Demarcate Identifier^ 







10 »This substitution applies iff the identifier denotes an 
attribute. 



30 



^This substitution, an identity, applies iff that of Note 1 
does not, i.e., if the identifier does not denote an 
attribute . 



35 



15 2.3.7 Selector Execution 

A "selector" achieves a special execution effect. 
A selector is executed as follows; 



40 



break 

Makes operation "loop", "repeat", or "while" succeed. 
20 -Loop Missing" is thrown if neither operation is being 
performed. 



45 
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client 

Pushes onto the stack an unprotected reference to the 
current client. The "current client" is either the object 
25 requesting the feature the current method implements. 
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unless the requester is the Engine itself, e.g., if the 
feature's access is "system", or a nil, otherwise. 

continue 

Makes operation "loop", "repeat", or "while" begin 
5 its next performance, if any. "Loop Missing" is thrown if 
neither operation is being performed. 

^gg^late 

Is the same as executing an identifier for the 
operation that the current method implements, with these 
10 exceptions. Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. During method selection, the Engine bypasses 
the class to which the current method is native. The 
operation has been escalated. 

15 here 

Pushes onto the stack an unprotected reference to the 
current place. The "current place* is either the place 
the current process occupies, unless the process is an 
engine place, or a nil, otherwise. 

20 process 

Pushes onto the stack an unprotected reference to the 
current process. The "current process* is that of which 
the current method's performance is dynamically a part. 



sel^ 

25 Pushes onto the stack a reference to the current 

object. The "current object" is that performing the 
^ current method. The reference is protected iff a 

protected reference was used to request the current 
me thod ' s performance . 
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Causes the current method to succeed without its 
5 remaining items having been executed. The attribute or 

the operation's result, if there is one, shall be on the 
stack. 

5 2.3.8 Modifi^T- Fv^o^,i-s^y^ 

A modifier alters the execution of the item that 
follows it in a procedure. 
^5 "^^^ execution of various modifiers is provided for by 

the substitution rules. A modifier that the substitution 
10 rules leave intact is executed as follows: 

20 demarcate 

Causes the following identifier/ or qualified 
identifier, to be executed with these changes. If the 
stack does not include a mark, the Engine throws "Mark 
15 Missing". If the number of arguments required by the 
operation that the identifier denotes is fixed and less 
than the number of objects above the mark, the Engine 
throws "Argument Invalid". Otherwise, if the number of 
arguments is fixed and greater than the number of objects 
20 above the mark, the Engine inserts in the stack, between 
the mark and the objects supplied, as many nils are there 
35 are arguments missing. The Engine then excludes the mark 

from the stack and, if the operation succeeds but does not 
produce a result, returns a nil to the requester, in place 
25 of a result. 
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mention 

Avoids executing the object following the "mention" 
4S modifier, pushing a protected reference to that object 

onto the stack instead. 



50 



55 



30 useStarW 

Pushes onto the stack a reference to the stack itself 
before executing the following object. 
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2.3,9 Identifi er Execution 

The execution of an identifier for a class, an 
attribute, a property, or a variable is provided for by 
the substitution rules described above with respect to 
5 Tables A. 3 and A. 4. 

An identifier that the substitution rules leave 
intact- -one for an operation- -is executed as follows. 

The Engine throws "Responder Missing" if the stack i 
10 cleared, since the responder was to have been on top of 
the stack. The Engine throws "Feature Unavailable" if 
either the responder lacks the operation the identifier 
denotes or the requester lacks access to the operation. 
Otherwise, the Engine selects and performs a method for 
15 the operation as described in the sections below. 

Qualified Identifier 

A qualified identifier for an operation is executed 
in the same way as is an identifier which is not a 
qualified identifier, for that operation, with these 
20 exceptions. 

Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. Otherwise, the Engine requests operation 
"getClass", its argument being an identifier whose text ia 
25 the qualifier, and throws "Escalation Invalid" if the 
operation's result is neither the class to which the 
current method is native nor one of its immediate 
implementation superclasses. 

During method selection, the Engine confines itself 
30 to the result of operation "getClass" and its 

implementation superclasses. The operation has been 
escalated. 
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2.3.10 Method Selecting 

The Engine selects for an operation the first method 
it finds by searching the following four locations in the 
order in which they are listed here: 
5 • If the responder is a class, its class methods. 

• If the responder is a class, the class methods of its 
implementation superclasses, which are investigated 
in canonical order. 

• The instance methods of the responder' s class. 
10 • The instance methods of the implementation 

superclasses of the responder' s class, which are 
investigated in canonical order. 
If a method escalates the operation, the Engine 
attempts to select another, resuming its search after the 
15 class to which the method it selected previously is 
native. If it finds no method, the Engine throws 
25 "Escalation Invalid" . 

2-3.11 Method Performance 

The Engine performs, as follows, the method it 
20 selects for an operation. 

Arguments Fixed in Mumhft;^ 

If the operation requires a fixed number of 
arguments, the Engine throws "Argument Missing" if the 
stack's length is less than one plus that number, and 
25 throws "Argument Invalid" if an argument violates the 
argument's constraint. 
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Argument a Variable in Number 

If the operation requires a variable number of 
45 arguments, the Engine throws "Mark Missing" if the stack 

30 does not include a mark, and throws "Argument Invalid" if 
an argument violates the argument's constraint. 

so Performang^ 
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The Engine pops the responder from the stack, creates 
a frame for the method's performance, performs the method, 
and discards the frame. 

The following actions surround the method's 
5 performance. The Engine offers the operation's arguments, 
moving them from the requester's stack to the responder' s. 
If the number of arguments is variable, the mark is 
offered in this way as well. The Engine accepts the offer 
of the operation's result, if there is to be one, moving 
10 it from the responder' s stack to the requester's. 

Success 

If the method succeeds and the operation was to 
produce a result, the Engine does the following. If no 
result was produced, the Engine throws "Result Missing V 
15 If the result does not satisfy the result's constraint, 
the Engine throws "Result Invalid- . Either exception is 
handled as described below. 

Failure 

If the method fails and the operation was not to 
20 throw the exception it actually threw, the Engine 

substitutes "Unexpected Exception" for that exception. 

2.4 Proceaa Mn^^] 

The Instruction Set realizes the "process model" this 
section defines. 

25 2.4.1 Pypgggggg 

A "process" is a named, autonomous computation, it 
constitutes the Instruction Set's provision for 
multi-tasking. 

MQta: A process often represents something in the real 
world, e.g., a person, whose objectives the 
process seeks to further in the Network. 

No£s: There are two kinds of process, agent and place. 
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If one process has a reference to another/ the two 
can interact in the same way as can any two objects: by 
means of their respective features. Each argument or 
5 result of such a feature enables one process to convey to 
the other either a reference to, or a copy of, an object, 

2.4.2 Phages 

A process goes through phases. The Engine requests 
and the then potential process successfully performs 
10 operation "initialize". The Engine requests and the 
process successfully performs operation "live", a nil 
being supplied as the operation's argument. The Engine 
requests and the process performs operation "finalize". 

15 The normal progression of phases described above may 

be interrupted. If operation "initialize" throws an 
exception, the Engine terminates the process. If 
operation "live" throws an exception, the Engine either 
restarts the process by requesting operation "live" again, 

20 the exception being supplied as the operation's argument, 
if the permit the process holds allows this, or requests 
operation "finalize" otherwise. If operation "finalize" 
throws an exception, the Engine terminates the process. 

If the process exhausts its native or local permit in 

25 any phase above, the situation is as if the process had 
thrown "Permit Exhausted" . 

2.4.3 Threads 

Every process gives rise to an independent thread of 
execution which comprises, at any moment, the frames of 
30 the methods being performed on the process' initiative. 
The first such method is the one the process itself 
provides for operation "live" the second the one an object 
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provides for a feature that the method for operation 
"live" requests of that object, and so on, recursively. 

The Engine schedules all execution threads that are 
5 not blocked, e.g., waiting until a certain time, switching 
preemptively between them as necessitated by their 
priorities. All else being equal, the Engine favors 
neither the processes of one authority over those of 
another, the processes of one brand over those of another, 
10 nor one process over another of the same priority. 

Interruption 

When the Engine itself requests a feature of an 
object, i.e., a system feature, the feature's method is 
performed as part of the thread of the object's owner. 
15 The owner, in effect, is interrupted for that purpose. 

2.4.4 R^gourye? 

A "resource" is something about which certain 
guarantees can be made to a process throughout its 
performance of a particular procedure. The Engine may 
20 delay the process until it can make the guarantees. 
N2£e: Resources enable the definition of critical 

conditional regions. 
Nats: A resource is often a proxy for a physical 

resource (as exemplified below) . 
25 iiafeg: In an electronic mail system, e.g., an agent 

serving as a mailbox might include among its 
properties a database of delivered messages and 
a resource representing the database. The agent 
would obtain exclusive use of the resource 
before beginning the task of adding a newly 
delivered message to the database, thereby 
ensuring the database's integrity in the face of 
concurrent deliveries. 
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Because one process can convey a reference to an 
^ object to another process, every object must be prepared 

for the methods native to or inherited by its class to be 
5 performed concurrently by those processes. Resources 
10 enable objects to make such preparations. 

Resources are used to ensure that sequences of 
operations are carried out atomically. For one operation, 
such precautions generally are not required because the 
*5 10 Engine performs atomically all predefined operations 
except operations wait ^ "meet" and any predefined 
operation that performs a procedure supplied as either the 
responder, e.g., operation "do", or an argument, e.g., 
operation "restrict". 
15 IJatfi: The Engine performs operations "go" and "send" 

atomically. 

25 

Exclusive vs Shared 

A process can be guaranteed either shared or 
exclusive use of a resource. At any time, either no 

30 

20 processes have use of the resource, one process has 
"exclusive" use of it, or one or more processes have 
"shared" use of it. 

3S 

Condi tioq 

A process can be guaranteed that a resource is among 
25 one or more conditions identified when the request is 
^ made. At any time, a resource has a "condition" which is 

among one or more conditions defined when the resource was 
created. Denoted by an identifier, a resource's condition 
^ can be examined only by a process with use, shared or 

3 0 exclusive, of the resource, and can be modified only by a 
process with exclusive use of the resource. 

« 2.4.5 Permits 
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A "permit" grants capabilities to a process, its 
"subject". The capabilities represented by the bulk of 
the instruction Set, e.g., the Instruction Set's 
arithmetic operations, are implicitly granted to each 
5 process. Other capabilities are explicitly granted to 
particular processes by means of the permits assigned to 
those processes . 

Nats: The principal purpose of permits is, as far as 

18 possible, to prevent processes from consuming 

1° computer and communication resources in 

unintended amounts. This benefits users, who 
create the processes and may have to pay for 
them, but also providers , who must provide the 
resources that the processes consume. 
15 Uatfi: The resources mentioned above are not to be 
confused with members of class "Resource". 
There is no necessary connection between the 
two . 
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CaDabil^,^^.eg 

20 A permit grants capabilities in certain defined 

dimensions and amounts. 

A permit can grant a process a certain age, size, 
charges, priority, or authenticity. The charges to which 
a permit entitles its subject is called the subject's 
25 "allowance-. An amount in any of these dimensions is an 
integer. Age is measured in seconds, size in octets, and 
charges in "teleclicks" . Priority increases with its 
xnteger value. Authenticity is region-specific. 

A permit can grant a process the right to transport 
30 itself (attribute "canGo- of the permit) , create and 
transport clones of itself (attribute "canSend"), create 
other peer processes {attribute "canCreate") , set the 
permits of selected processes so as to decrease (attribute 
so "canDeny") or increase (attribute "canGrant") their 

35 capabilities, increase the actual charges of other 
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processes (attribute "canCharge" ) , or be restarted if 
terminated (attribute "canRestart " ) . An amount in any of 
these dimensions is a boolean, where a boolean whose value 
is "true" grants the right in question. 
5 Each dimension in which a permit can grant 

capabilities is represented by an attribute of the permit. 
If normally an integer, the attribute can be a nil 
instead, in which case the capability is granted in 
unlimited amount. 
10 lifit^: The charge, in teleclicks, for a service 

rendered to a process, whether by an Engine or 
by another process, can vary from place to 
place, from time to time, or both. The charges 
for some services, e.g., space, can be assessed 
15 per unit time, 

Statug 

A process' "status" identifies the process' exercised 
capabilities. The status of a process is the process' 
effective permit", which is described below, except that 
20 the permit's "age", "charges", "extent", and "priority- 
attributes are the process' actual age, charges, size, and 
priority, respectively. 



Effecti ve Permit; 

A process' -effective permit" identifies the process' 
25 allowed capabilities. At any time and place, this permit 
is the intersection of the process' native, regional, and 
local permits and any temporary permits in force. For 
this purpose, however, the native permit's "authenticity" 
attribute is considered a nil unless the process is in the 
30 region in which the process was created. 

The *• intersection" of two permits is itself a permit, 
each of whose native attributes, Ao, is the intersection of 
50 the like. named attributes. A, and A^, of the two permits in 

question. More specifically, Ao is either A,, if Aj is a 
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a nil; Aj, if is a nil; or the minimum of Aj and Aj, 
otherwise. The Engine notifies a process, e.g., by use of 
operation "restricted" which is described below, if any of 
the process'^ permits, once set, is set again. 
5 A process "violates- its permit by attempting to 

exercise a capability in an amount greater than is granted 
the process by the process' effective permit. Violating 
one's permit without also exhausting the permit provokes 
an exception. 

10 A process "exhausts" its permit by allowing the 

process' actual age, charges, or size to reach the age, 
charges, or size, respectively, that the process' 
effective permit would grant the process if none of the 
process' temporary permits were in force. Exhausting 

15 one's permit initiates one's termination. 

Native PBTTn^t 

A process' "native permit" identifies the 
capabilities granted to the process by the creator of the 
process. One process, the parent, sets this permit when 
20 the parent creates another process, the child. A peer 
process can decrease but not increase capabilities, if so 
empowered by the peer's own effective permit (attribute 
"canDeny") . 

Capabilities are transferred between processes but 
25 not created. The parent or peer cannot grant the child a 
capability, "X-, which the parent or peer does not have 
itself. Let "P- be the amount of -x" granted the parent 
or peer by its effective permit. Let "C" be the amount of 
"X" granted the child by the child's native permit. "C- 
30 shall not exceed "P". 

The charges capability ("X") is conserved. Let "A" 
be the amount of the parent's or peer's actual charges 
beforehand. "C" shall not exceed "P-A". The amount of 
the parent's or peer's actual charges afterwards is "A+C". 
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Regional Permiti 

A process' "regional permit" identifies the 
capabilities granted to the process by the region that 
includes the place the process occupies, A place of the 
5 region's authority can set the permit when the process 
enters the region and at any time thereafter, if so 
empowered by the place's own effective permit (attributes 
"canDeny" and "canGrant") - If a child enters using 
operation "new", not operation "go" or "send", however, 
10 the child's initial regional permit is made the parent's 
current regional permit. 

Local Permil; 

A process' "local permit" identifies the capabilities 
granted to the process by the place the process occupies. 

15 The place can set the permit when the process enters and 
at any time thereafter, if so empowered by the place's own 
effective permit (attributes "canDeny- and "canGrant") . 

When entering a place using a ticket, an agent 
requests certain capabilities of the place. The place, 

20 however, decides what capabilities the agent shall have. 
The place can allow the agent to enter with a local permit 
more or less capable than the one the agent requested. In 
the latter case, however, the trip fails, i.e., operation 
"go" or "send" throws an exception even though the agent 

25 has arrived. 

When entering a place by being created there, a 
process receives as the process' initial local permit one 
created with no initialization parameters. 



30 



Temporary Permi^? 

A process' zero or more "temporary permits" identify 
the capabilities the process grants itself temporarily. 
Each is put in force using operation "restrict" or 
"sponsor" for a specified procedure's performance. Such 
procedures can be nested. 
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Whenever the Engine requests a system feature, the 
responder's owner implicitly sponsors the operation's 
method using a temporary permit created with no 
initialization parameters. In this way, charges accrue to 
5 the owner. 

IJQtfi: Using a temporary permit, a process can hold in 

reserve a portion of the process' allowed age, 
charges, or size. If the process exhausts the 
bulk of this commodity, the process can use the 
portion held in reserve to take emergency 
action. 



20 2.4.6 Qwiasrghip 

Every object that is not itself a process is "owned" 
by one. A process and the objects it owns are the 
15 "artifacts" of that process. - 

Hats: Ownership is not to be confused with authority. 

Qbj^pt Cyt^atiQH 

Every object, ultimately, is created by passing by 
copy between methods either an argument of a feature or a 
20 feature's result. The new object--the copy that is 

passed- -is owned by either the object to whose method the 
copy is conveyed, if that object is a process, or that 
object's owner, otherwise. 



40 25 - When a process is destroyed, all of its artifacts are 
destroyed, and all remaining references to them voided. 

abject Stirring 

46 A place's artifacts can refer to its immediate 

superplace's artifacts, which constitutes a first realm 
30 and its own artifacts and those of its immediate 

subplaces, which collectively constitute a second realm 

50 
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but the Engine voids a reference passed between the two 
realms. 

Note: Thus fire walls are erected between places. 

2.4.7 Cloning 
5 A process can be given the capability to clone 

itself. A clone is one process that begins as a copy of 
another process, i.e., the "original", with these 
exceptions . 

The clone's identity, but not its authority, differs 
10 from the original's. 

The clone's native permit, which is also its local 
permit, is that given when the clone is created. Any 
temporary permits pending in the original, i.e., as a 
result of operation "restrict", are made more restrictive 
15 within the clone to the extent that the clone's native 
permit requires this. 

Wherever the original refers to itself or an object 
the original owns, the clone refers to itself or its own 
copy of that object, respectively. Wherever the original 
20 refers to an artifact of a third process, the clone has a 
voided reference. 

If the original, and thus the clone, are contacted 
objects, the clone's "contacts" attribute is cleared. 

2.4.8 pr^pdj^nq 

25 A region brands every process within it. 

A "brand" is a distinguishing mark bom by zero or 
more processes in a region. When an agent enters a 
region, the region gives the agent a new brand. When one 
process within the region creates another, the latter 

30 bears the brand of the former. Thus a brand denotes a 
process, e.g., an agent, that entered the region and all 
of the processes created there by the former process. 
No££: Brands enable tracking mechanisms, which are not 

themselves in the Instruction Set. 
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2.4.9 Contacts 
A "contact" represents and documents for one process, 

the "observer", its interaction with a second process, the 
"subject". A "contacted" process receives help from the 
5 Engine in maintaining its set of contacts. 

2.4.10 X^Ql^ti^pn 
A process is isolated under various circumstances, 

e.g., upon either parting from all its acquaintances using 
operation "partAll", initiating a trip, or terminating. 

To "isolate" a process is to void each reference to 
an artifact of the process that is held by an artifact of 
any other process, and to void each reference that an 
artifact of the process holds to an artifact of any other 
process. There are two exceptions. First, the place that 
15 the process occupies retains its references to the 

process, but not to the objects the process owns. Second, 
the process can continue to refer to the place the process 
occupies . 

2.4.11 T^m^nai^iqn 
20 A process is terminated in a way that enables the 

methods whose frames are involved in the process' thread 
of execution to conclude gracefully. 

Let (i) a, 1, and C be processes, (ii) an artifact of 
A request a feature of an artifact of B, (iii) an artifact 
25 of a in turn request a feature of an artifact of £, and 
(iv) ^ exhaust its native or local permit. The Engine 
then terminates ^ as follows. 

Unless a, and C are one and the same, the Engine 
throws "Permit Exhausted", returning control to the method 
30 of A, B, or C that most recently prepared, using operation 
"catch" for that exception. The method is resumed, but 
with A holding the local permit of fi, or whichever 
is either the object with which the method is associated 
or that object's owner, when the method finishes, either 
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succeeding or failing, the Engine reinstates the exhausted 
5 permit of A, re-initiating the above termination 

algorithm. 

After doing the above, the Engine (i) halts A. 
5 (ii) isolates (iii) presents & for diagnostic 
10 examination if the 0AM policy in force so requires, and 

(iv) destroys A. 

2.5 Network Model 

The Instruction Set realizes the "network model" this 
10 section defines. 

20 2.5.1 ftqgnC? 

An "agent" is a process that can move from place to 
place. 

An agent can transport itself to a particular 
25 15 destination via operation "go- or commission one or more 
clones to travel several destinations concurrently via 
operation "send". 

The "go" and "send" operations of the 
Instruction Set are its most distinctive and 
powerful aspect. In most network architectures, 
all processes are stationary and communicate by 
exchanging messages. In this one, some 
processes are stationary, but others are mobile, 
the former communicating by means of the latter. 
This is a paradigm shift. 

2.5.2 Places 

A "place" is a process that is the locale for zero or 
more other processes, each of which can refer to and thus 
interact with the place. 
30 li2££: Places represent the Instruction Set's only 

example of action at a distance. Places 
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interact by means of agents which travel between 
them . 

Engine Place va V irtual Plaf; ^^ 

There are two kinds of place. Every Engine sustains 
5 one "engine place", representing the Engine itself, and 
zero or more "virtual" places. 

Subplace vs Supemlace 

Any place except an engine place can occupy another 
place. If one place occupies another, either directly or 
10 indirectly, the former is a "subplace- of the latter, and 
the latter is a "superplace" of the former. If one place 
occupies another directly, the former is an "immediate 
subplace" of the latter, and the latter is the "immediate 
superplace" of the former, 

15 plaqg ffj,<gycirghy 

The places an Engine sustains can be arranged as the 
nodes of a tree, the "place hierarchy", in which the nodes 
represent places, the arcs between nodes the occupation 
relationship between the places the nodes represent. 
20 HQ£e: The tree's root represents the engine place, the 

other nodes virtual places. 

2.5.3 l£iSlS. 

A "trip" is an agent's move from one place, the 
trip's "origin", to another or the same place, the trip's 
25 "destination". A trip can fail, leaving the agent either 
at its origin or in a "transit" place, neither its origin 
nor its destination. 

Notfi: A trip may take a long time because sometimes 

the trip entails transporting the agent by means 

physical, not just logical, communication 
media . 
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Operation "a o" vs Operation "a^n d" 

An agent can travel to a single destination itself 
via operation "go" or commission one or more clones to 
travel to several destinations concurrently via operation 
5 "send". 

Jifita: The "send" operation transports a single 

representation of the agent to any particular 
Engine, even if several clones are being sent to 
places that that Engine sustains. Further 
savings, e.g., of ispace in memory of a computer, 
, can be achieved at that Engine. 

RQSt;r3.<?t;jl,opS 

The operation «go" or "send" shall be requested only 
by either the procedure of a method native to a subclass 
15 of class "Agent", or a procedure that is an item of such a 
procedure, recursively. The Engine throws "State 
Improper" otherwise. 

2.5.4 nck;^t;g 

A "ticket" describes an intended trip from the 
20 viewpoint of the agent taking the trip. The ticket's main 
purpose is to identify the trip's destination. 

Composition 

A ticket comprises a telename and a teleaddress of 
the destination, a citation to a class of which the 
25 destination is a member, the local permit the agent 
requires at the destination, the time interval within 
which the trip should be accomplished ideally, and the 
time interval within which the trip shall succeed or fail 
under any circumstances. 
30 lisatfi: Defining the desired time interval helps the 
Network decide how to distribute its 
communication resources among traveling agents. 



126 



EP0634 719 A2 



Note: The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
operation "restrict". 

5 Satisfaction 

A ticket is satisfied by any place of the identified 
name, address, emd class that agrees to the agent's 
arrival within the maximum time interval. 

If no place satisfies the ticket, the Network rejects 
10 the ticket. 

If a set of two or more places satisfy the ticket, 
the Network attempts a trip to successive members of the 
set until one agrees to the agent's arrival or all places 
that the Network approaches reject the agent's arrival. 
15 The order in which the Network approaches the set members, 
to what extent the Network's coverage of the set is 
complete, and whether the Network approaches places that 
join the set after the ticket is presented are undefined. 

2.5.5 Meetings 

10 A "meeting" is an opportunity for two occupants of 

the same place, which are both petitioned objects and thus 
agents, to interact with one another. The requesting 
agent is the "petitioner", the responding agent the 
"petitionee" . 



25 Meeting 

One agent can ask to "meet" another via operation 
"meet". The Engine not the petitioner requests 
operation "meeting" of the petitionee, supplying as an 
argument a contact for the petitioner. Meeting hinges 
30 upon that operation's outcome. 

The Engine gives the two agents references to one 
another iff the meeting is consummated by the success of 
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operation "meeting" . While they are meeting, the two 
agents are said to be "acquaintances" of one another. 

The Engine does not serialize meetings with an agent. 
That the agent is performing operation "meeting" already 
5 does not deter the Engine from requesting performance of 
operation "meeting" again. The agent must provide, e.g., 
by means, of a resource, any meeting serialization the 
agent requires. 

Parting 

10 Either of the two agents can "part" from one or all 

of its acquaintances, via operation "part" or "partAll", 
respectively. The Engine not the agent requests 
operation "parting" of the agent's acquaintance or 
acquaintances. The Engine supplies as an argument the 

15 contact the Engine before supplied as either an argument 
of operation "meeting" or the result of operation "meet". 
Unlike meeting, a successful parting does not hinge upon 
the outcome of operation "parting"; parting occurs 
immediately emd unconditionally. 

20 The Engine voids each agent's references to the 

artifacts of the other. 

The Engine does not serialize partings from an agent. 
That the agent is performing operation "parting" already 
does not deter the Engine from requesting performance of 

25 operation "parting" again. The agent must provide, e.g., 
by means of a resource, any parting serialization the 
agent requires. 

If both agents ask to part from one another, whether 
the Engine requests operation "parting" of either is 

3 0 undefined. 

The operation "meet", "part", or "partAll" shall be 
requested only by either the procedure of a method native 
to a subclass of class "Agent", or a procedure that is an 
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item of such a procedure, recursively. The Engine throws 
"State Improper" otherwise. 

2.5.6 Petitions 

A "petition" describes an intended meeting from the 
5 viewpoint of the petitioner. Its main purpose is to 
identify the petitionee. 

ComppsitiQn 

A petition comprises a telename of the petitionee, a 
citation to a class of which the petitionee is a member, 
10 and the time interval within which the meeting attempt 
shall succeed or fail under any circumstances. 
Notfi: The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
15 operation "restrict". 

Satisfartinr^ 

A petition is satisfied by any petitioned object of 
the identified name and class that agrees to the meeting 
within the maximum time interval. The petitionee must be 
20 an occupant of the same place as the petitioner at some 
point within the maximum time interval, but not 
necessarily at its start. 

If no petitioned object satisfies the petition, the 
Engine rejects the petition, 
25 If a set of two or more petitioned objects satisfy 

the petition, the Engine attempts a meeting with 
successive members of the set until one agrees to the 
meeting or all petitioned objects that the Engine 
approaches reject the meeting. The order in which the 
30 Engine approaches the set members, to what extent the 
Engine's coverage of the set is complete, and whether the 
Engine approaches agents that join the set after the 
petition is presented are undefined. 
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2.5.7 Occupation 

The occupants of a place can change over time, 

Entry 

A process can "enter", and thus occupy, a place in 
5 either of two ways. An agent can arrive at the place as a 
consequence of a trip, or one process at the place already 
can create another process of the place. In either case, 
the Engine not the arriving agent or the creating 
process requests operation "entering" of the place. A 
10 contact for the arriving agent or the created process is 
supplied as an argument of operation "entering" , 
Successful entry hinges upon the operation's outcome. 

The Engine gives the place and the process entering 
the place references to one another iff the entry is 
15 consummated, i.e., by the success of operation "entering". 
While occupying the place, the process is said to be an 
"occupant" of the place. 

The Engine does not serialize entries to a place. 
That the place is performing operation "entering" already 
20 does not deter the Engine from requesting operation 
"entering" again. The place must provide any entry 
serialization the place requires. 
35 Hfiite: Operation "entering" is involved even if a 

trip's origin and destination are the same. 
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25 Exit; 

A process can "exit", and thus no longer occupy, a 
place in either of two ways. An agent can depart from the 
place as a consequence of a trip, or one process at the 
place can destroy itself or another process at the place. 
30 In either case, the Engine not the departing agent or 
the destroying process requests operation "exiting- of 
the place. The same contact supplied as an argument of 
operation "entering" is supplied as an argument of 
operation "exiting". Unlike entry, a successful exit does 
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not hinge upon the latter operation's outcome; the exit 
already occurred. 

The Engine voids the references of the place and the 
process exiting it to the artifacts of one another. The 
5 Engine, furthermore, isolates the process. 

The Engine does not serialize exits from a place. 
That the place is performing operation "exiting" already 
does not deter the Engine from requesting operation 
"exiting" again. The place must provide any exit 
10 serialization the place requires. 

Nsts: Operation "exiting" is involved even if a trip's 

origin and destination are the same. 

2.5.8 Contacts 

The Engine offers places and agents assistance in 
15 maintaining their contacts with their occupants and their 
acquaintances, respectively. 

Oqcup^^t^ 

If a place is also a contacted object, the Engine 
maintains the place's contacts attribute in such a way 
20 that the attribute always includes the place's current 
occupants and none of its previous ones . 

The Engine includes in or excludes from the place's 
attribute a contact for a process at the moment the 
process enters or exits the place, respectively. 

25 Acquaintances 

If a petitioned object is also a contacted object, 
the Engine maintains its contacts attribute in such a way 
that the attribute always includes the object's current 
acquaintances and none of its previous ones. 

30 The Engine includes in the petitioner's or 

petitionee's attribute a contact for the petitionee or the 
petitioner when operation "meet" or "meeting" succeeds, 
respectively. 
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5 The Engine excludes the contacts from the attributes 

of both the petitioner and the petitionee when either 
process requests operation "part" or "partAll". 

fO 2.5.9 Citations 

S Within the Network, objects of certain classes are 

denoted by citations . 

15 Citations 

A "citation" identifies zero or more cited objects by 
title and, optionally, author, edition, or both author and 
10 edition. A citation identifies the author by the author's 
20 authority and, optionally, the author's identity. If a 

citation leaves any of the three characteristics 
undefined, the citation denotes all cited objects with the 
characteristics citation does define. 

25 

15 Author 

An "author" is the process that creates a cited 
object. Thus an author is identified by a telename. The 
30 authors of all editions of a title are peers. 

Title 

20 A "title" is a series of cited objects, one asserted 

^ to be backward or forward compatible with another. A 

title is denoted by an identifier, which is interpreted 
relative to the common authority of the title's authors. 

25 An "edition" is any of the cited objects in a title. 

An edition is denoted by two integers. One, interpreted 
relative to the title, denotes a major edition. The 

45 

other, interpreted relative to the first, denotes a minor 
edition. 
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Note: A title's first major or minor edition is 

usually assigned the number one or zero, 
respectively. 

Assigned Citations 
5 An "assigned citation" denotes one cited object by 

author, title, and edition, identifying the author by both 
its authority and its identity. The assigned citation 
thereby distinguishes the cited object from all other 
cited objects, and thus from the others in the assigned 
10 citation's own title. See discussion of telenamea below. 



One cited object, Oj, is "backward compatible" with 
another, 0|, iff Oj can be created by making to O, only 
changes of the kinds prescribed by a class of which both 
15 cited objects are members, the kinds of change chosen to 
ensure that a program written to process Oi can process O2 
as well. Under the same conditions, Oj is "forward 
compatible" with Oj- 

2.5.10 Telenamea 
20 Within the Network, objects of certain classes are 

denoted by telenames. 

Telenamea 

A "telename" identifies zero (if the telename is 
invalid) or more named objects by their authority and, 
25 optionally, their identity. If the telename leaves their 
identity undefined, the telename denotes all named objects 
of the identified authority. 

Authority 

A named object's "authority" is the entity, e.g., the 
3 0 person or the organization, responsible for the object. 
An authority is identified by an octet string, which 
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distinguishes the authority from all others in the 
Network, 

Two telenames are "peers" iff they identify the same 
authority. 

5 Hote: Authorities are created administratively, not 
programmatically. Identities, however, are 
created in both ways. 

Identity 

A named object's "identity" is the named object 
10 itself. An identity, like an authority, is identified by 
an octet string, which, even by itself, distinguishes the 
identity from all others in the Network. 

NfiSS: The octet string denoting an authority or an 

identity may have no meaning to a human being, 
15 The Instruction Set does not define how the 

octet string is assigned. 

Assigned Tfilpn^'"?? 

An "assigned telename" denotes exactly one named 
object by authority and identity. 

20 2.5.11 Teleaddr^fls^fl 

Within the Network, places are located by 
teleaddreases. 

The "Network" comprises all engine places and is 
divided into one or more regions. A "region" is one or 
25 more engine places operated, or provided, by a particular 
authority. 

Teleaddresaea 
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A "teleaddress" identifies zero {if the teleaddress 
is invalid) or more places by their region and/ 
optionally, their location. If the teleaddress leaves 
their location undefined, the teleaddress denotes all 
5 places in the identified region. 

Region 

A place's "region" is the region that contains the 
place. A region is identified in the same manner as is an 
authority (see discussion of telenames above) , and thus by 
10 an octet string, which distinguishes the region from all 
others in the Network. 

Location 

A place's "location" is any characteristic of the 
place selected for that purpose by the authority of the 
15 place's region. A location is identified by means of a 
string, which distinguishes the location from all others 
in the region. 

Two places in a region can have the same location, 
N^tfe: The location of a place might be, e.g., the 

20 computer system sustaining it. 

Nq££: The string denoting a location can, but need 

not, have meaning to a human being. The 
Instruction Set does not define how the string 
is assigned, and the manner of assignment 
25 varies, in general, from one region to another. 

A teleaddress can, but need not, offer advice on the 
routing of agents to the places the teleaddress denotes. 
The teleaddress does this by suggesting one or more 
30 regions through which such agents may be routed. In the 
absence of such "routing advice", the Network may be 
unable to transport agents to those places, e.g., if those 
places are far removed from an agent ' s source . 
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Assjcmed Teleaddressea 

An "assigned teleaddress" identifies one or more 
places because several places can have the same 
location --by their region and their location within the 
5 region. 

2.5.12 Interchange 

An "interchanged object" is an immutable object for 
which the Network can, but need not, substitute an 
equivalent object, which is found, e.g., at the 
10 destination, whenever the object's owner takes a trip, on 
which the object must accompany it, provided the 
interchanged object has a digest. Digests are described 
below. 

NQJta: Interchanged objects improve the performance of 

^5 operation "go" and "send" by sometimes allowing 

an Engine to avoid physically transporting the 
interchanged objects by substituting for them 
equivalent objects found, e.g., at the 
destination. 

20 lifitfi: Classes and packages are interchanged objects. 

An interchanged object is deemed equivalent to any 
other instance of the object's class whose digest equals 
that of the interchanged object. A "digest" is any 
25 object, other than a nil, that is suited to this purpose. 
For example, a digest can be a mathematical hash of a 
canonical binary representation of the interchanged 
object. 

Nstfi: An interchanged object improves the performance 

30 of operations "go" and "send" only if the object 

is larger than its digest. 

2 , 6 Timekeeping Model, 
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The Instruction Set realizes the "timekeeping model" 
this section defines. 

One can keep time in two ways. A time or a calendar 
time alike identifies a date and time, but the two differ 
5 in other respects. 

Note: Times can be converted to calendar times, and 

conversely. 

fiats: The Engine can internally represent times more 

compactly than it does calendar times. Thus 
times are better, in general, for storing and 
transporting dates and times. 



2.6.1 Time 

A "time" identifies a date and time of day to the 
precision of one second using Coordinated Universal Time 
15 (UTC) . A time also identifies the time zone in which the 
time was measured and to what extent, if any. Daylight 
Savings Time (DST) was in effect at that time, in that 
place. 

Hatfi: UTC is effectively what was formerly known as 

20 Greenwich Meam Time (GMT) , 

2.6.2 ga^end^r Um 

A "calendar time" has all the characteristics of a 
time, and others. In particular, a calendar time exposes 
to examination and modification the hour of the day, the 

25 minute of that hour, and the second of that minute. It 
exposes the year in the Gregorian calendar, the month of 
that year, and the day of that month. It exposes the days 
of the week and year. It also exposes the time zone's 
permanent offset in minutes from UTC and its seasonal 

30 offset in minutes from its permanent one. The time is DST 
if the latter offset is non-zero. 

Normalify 
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A calendar time makes each facet of the date and time 
of day accessible as an integer that is normally in a 
prescribed range. The hours are numbered in the range of 
[0, 24), the minutes in the range of [0, 60), and the 
5 seconds in the range of [0, 60]. seconds are numbered in 
the range of [0, 60], i.e., 61 possible values, to 
accommodate leap seconds. The year 1993, e.g., is denoted 
by the integer 1993, the months are numbered in the range 
[1, 12], and the days are numbered in the range [1, 3i] 

10 The days of the weeJc are numbered 1, 2^ 3, 4, S, 6 or 7, 
which represent Sunday, Monday, Tuesday, Wednesday, 
Thursday, Friday, and Saturday, respectively. The days of 
the year are numbered in [1, 366] , The permanent and 
seasonal offsets are both numbered in [-720, 720] . 

15 Nats: Positive numbers denote years A,D., and negative 

ones denote years B.C. 

Abnormality 

A calendar time may have facets whose integer values 
lie outside their normal ranges. It might identify the 

20 date, e.g., as September 32, by which October 2 is meant. 
Such abnormal values may result from manipulating a 
calendar time in useful ways, e.g., adding two to the day 
of the month, but must be eliminated before the calendar 
time can be considered correct. A calendar time is made 

25 correct in this sense by a process of normalization. 

Normal izat-ign 

A calendar time is "normalized" in the following 
steps, the first of which taJces into account the fact that 
any facet of a calendar time can be a nil: 

30 Defaults 

• The hour, minute, or second, if nil, is made zero. 
The year, month, or day, if nil, is made one. The 
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permanent or seasonal offset, if nil, is made that of 
a normalized calendar time denoting the current time. 

Offsets 

• The permanent and seasonal offsets are replaced by 
5 the result of transposing into [-720, 720] the 

remainders left by dividing the offsets by 24*60, 
i.e., by the integer value 1440. 

Timq 

• The second is placed in normal range by repeatedly 
10 adding or subtracting 60, each time respectively 

subtracting or adding one to the minute. The minute 
is placed in normal range by repeatedly adding or 
subtracting 60, each time respectively subtracting or 
adding one to the hour. The hour is placed in normal 
15 range by repeatedly adding or subtracting 24, each 

time respectively subtracting or adding one to the 
day . 

Date 

• The month is placed in normal range by repeatedly 
20 adding or subtracting 12, each time respectively 

subtracting or adding one to the year. The day is 
placed in (1, K] by adding or subtracting K, 
respectively subtracting or adding one to the month. 
K is the number of days in the subject month in the 
25 subject year. If one addition or subtraction does 

not place the day in the required interval, this 
entire step is taken again. In other words, the 
month is adjusted as described above before adjusting 
the day again. 

30 Days 

• The days of the week and year are set correctly. 
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5 Localize vs Globalize 

A calendar time can be modified to reflect another 

permanent or seasonal offset without altering the absolute 

point in time it identifies. A calendar time is 
10 5 "localized" if its offsets are made those of the current 

place. A calendar time is "globalized" if its offsets are 

made those of UTC. 

2.7 Pattern Matching Modgl^ 

The Instruction Set realizes the "pattern matching 
10 model" this section defines. 

20 ^ „ 

2.7,1 Pflttgrai? 

A "pattem** is a means for lexically analyzing a 

string. The pattern's "text", itself a string, prescribes 

2^ the criterion by which a string matches the pattern. 

15 A pattern's text is a series of tokens obeying the 

syntactic, and accompanying semantic, rules below. Given 

in BNP (Backus-Naur or Backus Normal Form) , the rules 

30 surround optional tokens by brackets {"[" and "] ") , They 

surround vertical bar ("|"), left bracket ("["), and right 

20 bracket ("]") by quotation marks {'"') to distinguish 

their use, in accord with BNF, in describing the text of 

35 any pattern, on the one hand, from their possible use as 

metacharacters in a particular text, on the other. 

Each token in a pattern's text is zero or more 

25 characters. The text is obtained by concatenating the 

tokens, and thus the characters. 

2.7.2 Structure 

45 

A pattern, i.e., its text, obeys this rule: 
50 Pattern : :.= Alternative ["|" Pattern! 
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50 



A string matches a pattern iff it matches any of its 
alternatives . 

Alternative 

An alternative obeys these rules: 

Alternative ::- [*] Components [$] 
Components Component [Components] 



A string matches an alternative iff successive substrings, 
with no gaps between them, match successive components of 
the alternative. If the alternative begins with a caret 
20 10 or ends with a dollar sign ("$"), the series of 

substrings must begin or end at the string's beginning or 
end, respectively. 



A component obeys this rule: 
15 Component item [* | + | ?] 

A string matches a component iff it either comprises zero 
or more substrings, each matching the item, if an asterisk 
("*") appears; comprises one or more such substrings, if a 
plus sign ("+■) appears; either matches the item or is 
20 cleared, if a question mark ("?") appears; or matches the 
item, otherwise. 

ItfilQ 

An item obeys this rule: 

^tem . ( Pattern ) | 

2^ CharacterClass "] " | 

Character 
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A string matches an item iff it matches either the 
pattern, the character class, or the character, whichever 
the item prescribes . 

CharaeterClaaa 
5 A character class obeys this rule: 

Characterclass : :o Characterltems 

A string matches a character class iff it matches the list 
of character items iff the caret (*) is not present . 

Characterltema 
10 A list of character items obeys these rules: 

Characterltems Characterltem [Characterltems]. 

Characterltem CharacterRange | Character 

A string matches a list of character items iff successive 
substrings of the string, with no gaps between them, match 
15 successive character items in the list. The series of 

substrings must begin at the string's beginning and end at 
the string's end. 

CharacterRanqq 

A character range obeys this rule: 

20 CharacterRange Character - Character 

A string matches a character range iff the string 
comprises one character after or equal to the first 
character and before or equal to the second. 
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Character 

A character obeys this rule : 

Character : : = . | \ metacharacter | character 

A string matches a character iff the string comprises 
5 either any one character, if a period (".") is present; 
the metacharacter r if a reverse slash ("X") is present; or 
the character, otherwise. 

Note : Thus the special meaning of a metacharacter is 

avoided if a reverse slash ("\") immediately 
10 precedes the metacharacter. 

2.7.3 Other Non- terminals 
character 

Any instance of class "Character" other than a 
metacharacter , 

15 metacharacter 

A metacharacter. 

2.7.4 Meta<?h^y4ct;gyg 

A pattern's text can include metacharacters- A 
metacharacter has a special meaning which is among the 
20 semantic rules that govern the text. The metacharacters 
are the characters in Table A. 5 and those, e.g., backspace 
tabulated for a character telescript's "String" token. 
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Metacharacter 
Vertical bar ( | ) 
Caret D 



Dollar sign ($).... 

Left parenthesis ("(") 

Right parenthesis ("j") 
10 Left bracket { [) 

Right bracket ( ] ) 

Asterisk (*) « . 

Plus sign (+) . . 

Question mark (?) 
15 Minus sign (-) 



Period ( . ) ... 
Reverse slash (\) 
follows . 



TABLE A. 5 

Separates alternatives. 

Either anchors to the string's 

beginning, or inverts the 

matching rules. 

Anchors to the string's end. 

Begins a nested pattern. 

Ends a nested pattern. 

Begins a character class. 

Ends a character class . 

An item zero or more times. 

An item one or more times. 

An item optionally. 

Separates the characters defining 

a range. 

Matches any character. 
Disarms the metacharacter that 



20 3 TELESCRTP T CIA5S OVERVIEWg 

Being object-oriented, the Instruction Set comprises 
certain predefined classes which are overviewed in this 
section of this appendix. These classes are divided into 
groups as discussed below. A subsection is devoted to 

25 each group. Within each subsection, a subsection is 
devoted to each class in the group. 

Being interpreted, the Instruction Set does not 
define statement forms--e.g., for control flow--but rather 
relies upon the operations of its classes. Thus the 

3 0 semantics of the Instruction Set are largely those of the 
predefined classes. 

3.1 Cgiroypg 

The Instruction Set's predefined classes are divided 
into groups, one of which is called the kernel. This 
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division serves pedagogic purposes alone, and is intended 
to suggest neither that the classes in groups other than 
the kernel can be implemented by means of the kernel, nor 
that an Engine need implement the classes in the kernel 
5 but not necessarily those in other groups. 
The following groups are defined: 

Kernel 

This group provides basic language machinery, e.g., 
classes, objects, references, procedures, execution, and 
10 exceptions. 

20 Primitives 

This group provides basic forms of indivisible 
information, e.g., booleans, octets, numbers, characters, 
and times. 



10 



15 



25 



30 



15 Collect ions 

This group provides basic forms of composite 
information, e.g., sets, lists, stacks, strings, and 
dictionaries. 



35 20 This group provides the component parts of class 

definitions, e.g., interfaces, attributes, operations, 
implementations, and methods. 

^ Identificat;^9j^ 

This group provides, for naming and addressing, e.g., 
25 telenames and teleaddresses. 

45 

Proceaaea 

This group provides for multi-tasking, e.g., 
processes, permits, resources, and contacts. 

50 

ftqentjg ^q<a Places 
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This group provides for process movement within a 
network, e.g., places, agents, and tickets. 



10 



15 



20 



Meetings 

This group provides for process interaction within a 
5 network node, e.g., meeting places and petitions. 

M i s ce 1 1 aneous 

This group provides a variety of things, e.g., a 
random number generator and a pattern matcher. 

The groups are presented below in the order in which 
10 they are listed above. The classes within each group are 
presented in alphabetical order. 



25 



30 



35 



40 



45 



50 



15 



20 



25 



30 



3*2 Kernel Group 
Object (Referenced) 

Ciaaa (cited & interchanged) 
Collection 

• Set (Verified) 

• • Constrained Set (Constrained) 

• • • Package (Cited & Interchanged) 
Constraint 

Except ioT^ (Unchanged) 

• Program ming Except inyT i 

• • Kernel E xcept ior^ 

• ♦ • Executio n Exceotipn 

• • • • Unexpected Exception 
Primitive (Executed & Unchanged) 

• Identifier (Ordered) 
• Qualifie d Identi^ip^i; 

Modifier 
Nil 

Procedure 
Constrain^f^ 
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Executed 
5 Referenced 

Unchanged 
Verified 

5 3.2.1 Class 

convert 
ielnstance 
isMember 
10 isSubclass 
new 

A "class" is an immutable object that defines a set 
of objects, the class' instances. 

A class' native operations create a new instance via 
15 operation "new", convert an instance of another class to 
an instance of this one via operation "convert", indicate 
whether an object is an instance via operation 
"islnstance" or a member via operation "isMember" of the 
class, and indicate whether another class is a subclass of 
20 the present one via operation "isSubclass". 



15 



20 



25 



30 



40 



3.2.2 CQn^t;yai^^^ 
35 Attributea 

constraint 

A "constrained object" enforces a constraint upon 
25 those of its properties identified by another class of 
which the object is a member. 

A constrained object's native attribute is the 
constraint (attribute "constraint") . 
^ fio£e: Constrained dictionaries, lists, and sets are 

3^ constrained objects. 

3.2.3 Constraint 
«> Attribute^ 

classid 
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50 



islnstance 
isOptional 
ofClass 
passage 

5 A "constraint" is an object defining restrictions 

placed upon other objects, 

A constraint's native attributes are the identifier 
of the class of which the constraint's sxibjects shall be 
members (attribute "classid"), the class itself (attribute 
10 "ofClass"), whether the subjects shall be instances of 
that class (attribute "islnstance"), whether the subjects 
may be nils (attribute "isOptional") , and the subjects' 
passage (attribute "passage") . 

3,2,4 Exceptip^ 
15 Opey^tj^Qflg 

throw 

An "exception" is an object describing a performance 
or execution failure. 

An exception's native operation throws the exception 
20 (operation "throw"). 



3.2.5 Executed 
Qperationg 

catch 
do 

25 either 
if 

loop 
repeat 
^ while 

An "executed object" is permitted as an item of a 
procedure , 

An executed object's native operations perform the 
executed object (i) once via operation "do", (ii) once 
catching certain exceptions via operation "catch", (iii) 
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once iff a precondition is satisfied via operation "if", 
(iv) a certain number of times via operation "repeat", (v) 
indefinitely many times via operation "loop", or (vi) as 
often as another executed object's performance dictates 
5 via operation "while". An additional operation decides 
which of two executed objects to perform (operation 
"either") . 

Note : Instances of the predefined concrete subclasses 

of class "Primitive", as well as the predefined 
10 subclasses of class "Constrained List", are 

executed objects. 

3.2.6 R^^CHtiCT Ex<?gpti,pn 

An "execution exception" is a kernel exception that 
indicates that the Engine is unable to execute an item of 
15 a procedure. 

Among this class' predefined subclasses is "Internal 
Exception", a member of which indicates that the Engine 
fails to implement an aspect of the Instruction Set. The 
ideal Engine never throws such an exception, but an actual 
20 Engine does. The latter' s documentation says when, e.g., 
when the sum of two integers is too large for the Engine 
to conveniently represent internally. 

3.2.7 Identifier 

An "identifier" is a primitive that distinguishes one 
25 object from others in a particular context. 

3.2.8 Kernel Exception 

A "kernel exception" is a programming exception 
thrown by members of the classes in this section. 

3.2.9 Mark 

30 A "mark" is a primitive with one possible value, 

"mark", A mark is used to demarcate a series of objects, 
usually the topmost items of a stack. 
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3.2.10 Modifier 

A "modifier" is a primitive with these possible 
values : "demarcate" , "getClass" , "getProperty" , 
"getvariable", "mention-, "setAttribute" , "setProperty" , 
"setVariable", and "useStack" . A modifier is used to 
alter the execution of the item that immediately follows 
the modifier in a procedure, 

3.2.11 Nil 

A "nil" is a primitive with one possible value, 
"nil". A nil is used to indicate the absence, e.g., on 
the stack, of a member of another class. 



3.2.12 Object 
Attribute^ 
class 
15 size 
Op^rat^jopg 

copy 

30 finalize 

initialize 
20 isEgual 
select 
Internal Operations 

getAttribute 
getClass 
40 25 getProperty 

getVariable 
setAttribute 
setProperty 
setvariable 

30 An "object" is the Instruction Set's unit of both 

information and information processing. An object is an 
instance of a class. 

An object's native attributes are its class ("class") 
and its size ("size"). 
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An object's native operations initialize (operation 
"initialize") and finalize (operation "finalize") the 
object; decide whether the object equals another object 
(operation "isEqual"); decide which, if any, of several 
5 objects the former object equals, and perform the executed 
object paired with that object (operation "select"); and 
create a separate' but equal copy of itself (operation 
"copy") . 

An object has a number of internal features. An 
10 "internal" feature is a system feature that is sealed by 
class "Object" and, furthermore, that does not prevent a 
feature native to a user-defined subclass of class 
"Object" from having the same identifier. Thus an 
internal feature is fictitious. Its only purpose is to 
15 simplify the definition of the Instruction Set, especially 
its execution model. 

An object's internal operations bind to objects at 
run time the identifiers used in the interface and 
implementation of the object's class. Thus an object can 
20 (i) get via operation "getAttribute" , or set, via 

operation "setAttribute" , the attribute of itself that a 
certain identifier denotes, (ii) get via operation 
"getProperty" , or set via operation "setProperty", the 
property of itself that a certain identifier denotes, 
25 (iii) get, via operation " get Variable » , or set, via 
opeation "aetVariable" , the variable that a certain 
identifier denotes, and, (iv) identify and locate the 
class that a certain identifier denotes via operation 
"getClass" . 

30 3.2.13 Package 

A "package" is a constrained set of classes. A 
package, furthermore, is a cited object, a peer of each 
class the package comprises. 

One package is backward compatible with another iff 
3 5 the former can be created from the latter by making only 
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changes of the following kinds. First, a new class may be 
added. Second, an existing class may be replaced with one 
backward compatible with the existing class. 

3.2.14 Procedure 

5 A "procedure" is a primitive comprising an ordered 

set of executed objects. 

3.2.15 Programming Exception 

A "programming exception" is an exception that 
indicates that a programming mistake was made in the 
10 provision or use of a feature. 

3.2.16 Qualified Identifier 

A "qualified identifier" is an identifier that 
denotes a feature and a class to which an implementation 
of the feature is either native or inherited. 

15 3.2.17 Referenced 
^fVt^ril?ut;eg 

isProtected 

Qper^tjQna 

discard 
20 isSame 
protect 
ref 

A "referenced" object is one to which references can 
be obtained. Its features manipulate the references used 
25 to request them, not the object itself, 

A referenced object's native attribute reveals 
whether a reference is protected (attribute 
"isProtected") . 

A referenced object's native operations create new 
30 references to the object (operation "ref"), protected if 
desired (operation "protect"); discard an existing 
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reference (operation "discard"); and say whether two 
references are to the same object (operation "isSame") . 
Notg: All objects are referenced objects. The present 
class, then, is defined for purely pedagogic 
5 reasons. 

3.2.18 Selector 

A "selector" is a primitive with these possible 
values: "break", "client", "continue", "escalate", "here", 
"process", "self", and "succeed". A selector is used to 
10 achieve a special execution effect. 

3.2.19 Unchanged 

An "unchanged" object cannot be changed. The meaning 
of "change" depends upon the other classes of which the 
unchanged object is a member. An unchanged object often 
15 is described as "immutable". 

Members of classes "Class", "Exception", 
"Package", "Primitive", and "Time" are 
immutable . 



3.2.20 Unexpect ed Excepting 
20 ACtyibut;^? 
35 exception 

An "unexpected exception" is an execution exception 
that indicates that a feature threw an exception whose 
class the feature does not declare. 
25 An unexpected exception's native attribute is the 

undeclared exception (attribute "exception"). 



3.2.21 V^rX^X^d, 
Qperationa 

verify 

30 A "verified object" can become internally 

so inconsistent in one or more ways which depend upon the 

other classes of which the object is a member. 
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A verified object's native operation indicates 
whether the object is internally consistent (operation 
"verify") . 

Nstfi: Sets are verified objects. 

5 3.3 Primitive ^-^rr^VP 
Ob j ect (Referenced) 

Exception (Unchanged) 

Programming Exception 
• Primitive Exception 
Primitive (Executed & Unchanged) 



15 



Sit (Ordered) 
Boolean (Ordered) 
Ct^ajr^<?tQr (cased & Ordered) 
NumbQ?^ (Ordered) 

• Real 

2££jat (Ordered) 
Telenumber 

lima (Ordered & Unchanged) 



20 Cased 
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3.3.1 Bit 

A "bit" is a primitive with two possible values, 
"zero" and "one«, 

25 3.3.2 Boolean 

Qpgr^tiQng 

ctnd 
not 
or 

30 A "boolean" is a primitive with two possible values, 

"false" and "true". 
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A boolean' s native operations make it capable of 
logical conjunction (operation "and"), disjunction 
{operation "or"), and negation (operation "not"). 

3.3.3 Cased 
5 Attributes 

is Lower 
isUpper 

Operate ions 

makeLower 
10 maJceUpper 

A "cased" object comprises character information. 
Such information, and thus the cased object itself, can be 
upper-case, lower-case, or a mix of the two, 

A cased object's native attributes indicate whether 
15 any character information is lower-case (attribute 
"isLower") or upper-case (attribute "isUpper") . 

A cased object's native operations produce an all 
lower-case (operation "makeLower") or an all upper-case 
(operation "makeUpper") equivalent of the object. 
20 Not^ : Two cased objects can be compared without regard 

for their cases by using operation »'isEqual" in 
combination with either operation "makeLower" or 
operation "makeUpper" , 
No££: Characters and strings are cased objects. 

25 3.3.4 Character 

A "character" is a primitive whose possible values 
are the Unicode characters [Unicode] . 

3.3.5 xncgqgy 

Operations 
30 modulus 
quotient 

An "integer" is a number that is also an integer. 
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An integer's native operations perform integer 
division and produce either the quotient (operation 
"quotient") or the remainder (operation "modulus") that 
results, 

5 Not^: Internally the Engine may represent integers 

with only finite precision. Not all integers, 
therefore, are necessarily instances of this 
class in practice. 



3,3.6 Nymbgg 
10 Operations 

abs 
add 

ceiling 
divide 
15 floor 

multiply 
negate 
round 

30 subtract 
20 truncate 

A "number- is a primitive that is capable of basic 
arithmetic operations. 

A number's native operations perform addition 
(operation "add"), subtraction (operation "subtract"), 
25 multiplication (operation "multiply"), and division 

(operation "divide"); negation (operation -negate") and 
absolute value (operation "abs"); rounding (operation 
"round") and truncation (operation "truncate"); and the 
floor (operation "floor") and ceiling (operation 
4S 30 "ceiling") functions. 

3.3.7 Octet 

An "octet" is a primitive comprising eight bits. For 
reference purposes, the bits are designated Bit 7 through 
Bit 0. 
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3.3.8 Ordered 
Operations 

isAfter 
isBefore 
5 max 
min 

An "ordered" object is a member of another class 
whose members can be ordered by placing any one either 
before, after, or coincident with any other. The meanings 
10 of "before" and "after" depend upon that class. 

An ordered object's native operations indicate 
whether one such object is before (operation "isBefore") 
or after another (operation "isAfter"), and which of two 
is the minimum (operation "min") or the maximum (operation 
15 "max") . 

NaJtfi: Whether two ordered objects are coincident is 

indicated by operation "isEqual". 
Mfitfi: Instances of many classes. are ordered objects. 

3.3.9 Primitive 

20 A "primitive" is an object that is an Instruction Set 

primitive. 

N^tfi: Not every Instruction Set primitive is a member 

of this class. 

3.3.10 Primitive Except ip^ 

25 A "primitive exception" is a programming exception 

thrown by members of the classes in this section. 

3.3.11 Telenumber 
Attributes 

country 
30 extension 
telephone 
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A "telenumber" is an object giving the address of a 
5 telephone instrument in the international telephone 

network, i.e., a telephone number. 

A telenumber' s native attributes are the code for the 
5 country in which the instrument is located ("country"), 
number the country assigns to the instrument 
("telephone"), and its telephone extension, if any 
("extension") . 

3.3.12 Timfi 
10 Operations 

adjust 

20 interval 

A "time" is an object that identifies a date and time 
of day to the precision of one second using OTC. A time 
15 also records the time zone in which it was measured and to 
25 what extent, if any, DST was in effect then and there. 

A time's native operations adjust the time by any 
number of seconds (operation "adjust") and give the 
interval between the time and another time (operation 
^ 20 "interval") , 



35 



3.4 Collection Groun 
Object (Referenced) 

Association (Ordered) 
Collection 

List (Ordered) 

Constrained List; (Constrained) 

• Bit StriT^q (Executed) 

• Octet- Stri.yTiq (Executed) 

• Strir^g (Cased & Executed) 
Stack 

Sgt (Verified) 

Constrained^ Sfif; (Constrained) 

Dictionary 

• Constrained Dictionary (Constrained) 
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• • • • Lexicon 
Except ion ( Unchanged) 

• Programming Exception 

• • Collection Exrpp^^r>p 

Hashed 

3.4.1 Association^ 
Attributes 
key 

10 value 

An "association" is one object that comprises two 
objects, which are the one object's "key" and "value". 

An association's native attributes are its key 
(attribute "key") and its value (attribute "value"). 
15 NGta: Associations are used to create dictionaries. 



3.4,2 Bit St 

are 



A "bit string" is a constrained list whose items 



instances of class "Bit". 



3.4.3 CpU^gtiQn 

20 At;t;ributft^ 

length 

Operations 

clear 
examine 
25 exclude 
include 
stream 

46 A "collection" is an object that comprises an 

unordered set of zero or more other objects, its "items", 
30 which are among its properties. A collection's "length" 
is the number of the collection's items. The collection 
is "cleared" if its length is zero. A subclass of class 
"Collection" can restrict its members' items. 
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A collection's native attribute is the collection's 
^ length (attribute "length") . 

A collection's native operations include an object as 
a new item (operation "include"), exclude an existing item 
5 (operation "exclude"), exclude all existing items 
10 (opeation "clear") , arrange for an item's inspection 

(operation "examine"), and produce a stream whose items 
are those of the collection (operation "stream") . 
fitote: A collection's length is unbounded. 
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10 3.4.4 collection Exceptinr^ 

A "collection exception" is a programming exception 
thrown by members of the classes in this section . 

3.4.5 Constrained Dictionary 

A "constrained dictionary" is a dictionary whose keys 
15 are restricted by means of a constraint, a single 
constraint governing the entire dictionary. 

3.4.6 Constrained Lj^i^^^ 

A "constrained list" is a list whose items are 
restricted by means of a constraint, a single constraint 
20 governing the entire list. 



3.4.7 Constrained Set 

A constrained set is a set whose items are restricted 
by means of a constraint, a single constraint governing 
40 the entire set. 

25 3.4.8 DictionaiTy 
Operations 

add 
drop 
find 

30 get 

rekey 
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set 

transpose 

A "dictionary" is a set whose items are associations. 
A subclass of class "Dictionary" can restrict its members' 
5 keys, values, or both. 

A dictionary's native operations include an 
association between a certain key and a certain value as a 
new item (operation "add"), exclude the association with a 
certain key (operation "drop"), determine a key's 
10 associated value (operation "get"), replace a key's 

associated value (operation "set"), determine a value's 
associated key (operation "find"), replace one key with 
another (operation "rekey") , and transpose two keys 
(operation "transpose"). 



15 3.4.9 Hashed 
25 Att;ni?M^<gg 
hash 

A "hashed" object is a member of another class for 
which a hash function is defined. Each member of that 
20 class computes its own hash, an integer, ensuring that if 
two members are equal, their hashes are equal, 

A hashed object's native attribute is the hash 
^ function for that object (attribute "hash"). 

No£e: If a dictionary's keys are hashed objects, the 

25 dictionary can, but need not, use attribute 

"hash" in the performance of some of the 
40 dictionary's operations. 

liQtfi: No instances of predefined classes are hashed 

objects. 



30 3.4.10 Lexicon 

A "lexicon" is a constrained dictionary whose keys 
are identifiers. 

3.4.11 List 
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Operations 

add 

5 

drop 
find 
5 get 
10 reposition 

set 

transpose 

A "list- is a collection whose items are numbered in 
10 [1, n], "n" being the collection's length. An item's 
number is the item's "position" in the list. 

A list's native operations include an object as a new 
item (operation "add"), exclude an existing item 
(operation "drop"), arrange for an item's inspection 
15 (operation "get"), replace an existing item (operation 
"set"), determine an existing item's position (operation 
25 "find"), reposition an existing item (operation 

"reposition"), and transpose two existing items (operation 
"transpose") . 

^ 20 3.4.12 Octet Stn^n^ 

An "octet string" is a constrained list whose items 
are instances of class "Octet". 

35 

3.4,13 Set 

Qperationfl 
25 difference 
40 intersection 
union 

A "set" is a collection no two of whose items are 
equal when included. 

^30 A set's native operations compute the union 

(operation "union") or intersection (operation 
"intersection") of two sets and exclude those items in one 

^ that equal items in the other (operation "difference") . 
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Note: An item's modification in situ, may leave two 

g items equal , 

3.4.14 Stack 

Operating 
10 5 pop 

push 

pushltems 
roll 
swap 

10 A "Stack" is a list whose items are usually dropped 

in the order that is the opposite of that in which they 
were added. The stack's "top- is' position one, the 
stack's "bottom*' the position that is the stack's length. 
A stack's native operations add an object at the top 
15 (operation "push"), add the items of a list at the top 
(operation "pushltems*), drop the item at the top 
(operation "pop"), transpose the two items at the top 
(operation "swap"), and roll a certain number of the 
topmost items a certain number of positions (operation 
30 20 "roll") , 

3.4.15 stxaam 

Attributes 

current 
isDone 
25 next 

A "stream" is an object that provides sequential 
access to the objects in an associated series of objects, 
the stream's "items". A stream never "produces" the same 
item twice, and produces a nil after producing the last 
45 30 item. 

A stream's native attributes enable it to produce its 
next item upon request (attribute "next"), reproduce the 
item it produced most recently (attribute "current"), and 
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indicate whether or not it has yet produced its last item 
(attribute "isDone"). 

Nat£: If an item of the stream is itself a nil, this 

fact must be taken into account when 
5 interpreting the "next" or "current" attribute. 

3.4.16 String 

substring 

A "string" is a constrained list whose items are 
10 instances of class "Character" . 

A string's native operation produces a copy of a 
substring (operation "substring"). A substring is a 
series of zero or more characters occupying successive 
positions in a string. A substring is defined by two 
15 positions, Pi and Pj, the substring's items being those at 
positions [P,, Pj) of the string. 
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3.5 Class Definition Gr-g^^j^ 
Object (Referenced) 

Class Definition 
Exception (Unchanged) 

• Programming Exception 

• • Class Eyrppl;inn 
Feature 

• AttrjLbu^g 

• Operation 
Implementa^;7,9n 
Interface 
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3.5.1 Attyj,but;e 
30 Attributea 

constraint 
isSet 
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An "attribute definition", i.e, a member of class 
"Attribute", is a feature definition for an attribute. 

An attribute definition's native attributes define 
how the attribute is constrained (attribute "constraint") 
5 and whether it can be set (attribute "isSet") . The former 
affects both the result of operation "crGet" and, if the 
attribute can be set, the argument of operation "aSet". 

3.5.2 Class Definition 

Attributes 
10 implementation 
interface 
20 majorEdition 
minorEdition 
title 

15 QperationB 

makeClasses 

A "class definition" is an object that defines a 
class . 

A class definition's native attributes define the 
20 class' interface (attribute "interface"), implementation 
(attribute "implementation"), title (attribute "title"), 
major edition (attribute "majorEdition"), and minor 
35 edition (attribute "minorEdition") . 

A class definition's native operation creates the set 
25 of one or more classes that a set of as many class 
definitions define (operation "makeClasses"). Any 
required references among the classes are established as 
the classes are created. The process requesting the 
operation is the classes' author. 
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30 3.5.3 Class Exception 

A "class exception" is a programming exception thrown 
by members of the classes in this section, 

3.5.4 Feature 
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Attributes 

exceptions 
isPtiblic 

A "feature definition", i.e, a member of class 
5 "Feature", is an object that defines a particular feature 
of every member of the class of whose interface the 
feature definition is a part. 

A feature definition's native attributes define 
whether the feature is public, not private (attribute 
10 "isPublic"), and the classes of which the feature's 

exceptions are members (attribute "exceptions"). A system 
feature is not subject to a feature definition. 



3.5.5 Implementatinn 

Attributes 

15 clasi9Methods 
fromMethods 
i ns t anc eMe t hods 
properties 
setMethods 
20 superclasses 
toMethods 
vocabulary 

An "implementation" is an object that implements 
selected features and conversions native to or inherited 
25 by the class of which the implementation is a part. 

An implementation's native attributes identify the 
implementation's immediate implementation superclasses 
(attribute "superclasses"); provide methods for selected 
class features (attribute "classMethods") , instance 
30 features (attribute " ins tanceMet hods" and attribute 
^ "setMethods"), and conversions from (attribute 

"fromMethods") and to (attribute "toMethods") other 
classes; define properties native to the class (attribute 
"properties"); and define the identifiers the 

50 
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implementation uses to denote user-defined classes 
(attribute "vocabulary") . 

3.5.6 Interface 

5 classFeatures 

instanceFeatures 
isAbstract 
sealedClassFeatures 
sealedlnstanceFeaturee 
10 superclasses 
vocabulary 

An "interface" is an object that defines the features 
native to the class of which the interface is a part. 

An interface's native attributes define whether the 
15 class is abstract {attribute "isAbstract"), identify the 
class' immediate interface superclasses (attribute 
"superclasses"), define the class' native class features 
(attribute "classFeatures") and instance features 
(attribute "instanceFeatures"), identify the class 
20 features (attribute "sealedClassFeatures") and instance 
features (attribute "sealedlnstanceFeatures") that the 
class seals, and define the identifiers the interface uses 
to denote user-defined classes (attribute "vocabulary"), 

3.5,7 Method 
25 Attribu^_A« 

procedure 
variables 

A "method" is an object that is used to implement a 
feature. 

30 A method's native attributes are the method's 

procedure (attribute "procedure") and the identifiers of 
the method's variables (attribute "variables"). 
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3.5.8 Operation 
Attribvt;^3 

arguments 
result 

5 An "operation definition", i.e., a member of class 

"Operation", is a feature definition for an operation. 

An operation definition's native attributes define 
whether the operation's arguments are variable or fixed in 
number and, in the latter case, how each argument is 
10 constrained (attribute "arguments"). The attributes also 
define whether the operation has a result and, if so, how 
the result is constrained (attribute "result"). 



3-6 Identification Group 
Object (Referenced) 
15 • Citation (Ordered) 

• Teleaddress 

• Telenan^e 
Cited 

30 Nam^ 

20 3.6.1 Citation 
Attributq fs 

author 
majorEdition 
minorEdition 
25 title 

A "citation" is an object that identifies zero or 
more editions, e.g., classes, in the Telescript Network. 
A citation's native attributes define the title in 
45 Which the editions appear (attribute "title"); optionally, 

30 the title's author (attribute "author"); and, optionally, 
the editions' major edition (attribute "majorEdition"), 
minor edition (attribute "minorEdition"), or both. 



3.6,2 pit:?a 
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Att;rj.but^^ 

citation 

A -cited" object is one having an assigned citation. 
Two cited objects are peers iff the assigned telenames in 
5 their assigned citations are peers. 

A cited object's native attribute is the object's 
assigned citation (attribute "citation") . 
Note: Classes and packages are cited objects. 



3.6.3 Named 
10 Attribiit^ 

name 

A "named- object is one having an assigned telename. 
Two named objects are peers iff their assigned telenames 
are peers. 

15 A named object's native attribute is the object's. 

25 assigned telename (attribute "name"). 

Nq£s: Processes are named objects. 



3.6.4 Teleaddr^fl.? 

Att;yj,bur,e^ 
20 location 
provider 
routingAdvice 
A "teleaddress" is an object that locates zero or 
more places in the Telescript Network. 
25 A teleaddress' native attributes give the places' 

region (attribute "provider"); optionally, the places' 
location (attribute "location"); and any routing advice 
(attribute "routingAdvice"). 



3-6.5 Telgnamft 

30 Attribi^t;apf 

authority 
50 identity 
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A "telename" is an object that identifies zero or 
more named objects in the Network. 

A telename's native attributes define the named 
objects' authority (attribute "authority") and, 
5 optionally, the single named object's identity' (attribute 
"identity") . 

3-7 Process (?r'?'T 
Object (Referenced) 

• Contact 

10 • Exception (Unchanged) 

• • Programming Exception 

• • • Process RxcenHf^n 

• Permif. (Ordered)' 

• Proceaa (Named) 



15 



Contacted 



3-7.1 Contacl;; 
Atl;rj^>?vig<|>is» 

subject 
20 svibjectClasB 
subjectName 
subjectNotes 
A "contact" is an object that represents and 
documents for one process its interaction with another. 
25 A contact's native attributes are the subject 

(attribute "subject"), the subject's assigned telename 
(attribute "subjectName"), the subject's class' assigned 
citation (attribute -subjectClass") , and an object the 
observer maintains (attribute "subjectNotes"). Even if 
30 the subject attribute is a nil, as it may be, the Engine 
guarantees the authenticity of the other attributes, 
liats: Typically the "subjectNotes" attribute is the 
state of the interaction between the two 
processes from the observer's viewpoint. 
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3.7.2 Contact^ 

5 ■ 

contacts 

A "contacted" object, necessarily a process, receives 
5 help from the Engine in maintaining the object's set of 
10 contacts. ' 

A contacted object's native attribute is the object's 
contacts (attribute "contacts") . 

E2£S.- Instances of no predefined classes are contacted 

10 objects. 

3.7.3 Permit; 

A "permit- is an object that grants capabilities to a 
process . 



15 
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25 15 age 

authenticity 
canCharge 
canCreate 
canDeny 
20 canGo 

canGrant 
canRestart 
canSend 
charges 
25 extent 

priority 

A permit's native attributes include integers that 
define the maximum age (attribute "age-), size (attribute 
"extent-), charges (attribute "charges"), priority 
30 (attribute "priority-), and authenticity (attribute 
"authenticity-) of the permit's subject. 

A permit's native attributes include booleans that 
can permit the subject to request operation "charge- 
(attribute "canCharge"), operation "go- (attribute 
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"canGo-l, operation "send" (attribute "canSend"), or 
^ operation "new" of a subclass of class "Process" 

(attribute "canCreate") ; deny (attribute "canOeny") or 
grant (attribute "canGrant") capabilities via certain 
5 permits of certain processes; and be restarted (attribute 
10 "canRestart") . 

Operation^ 

intersection 

IS 

A permit's native operation return the intersection 
10 of two permits (operation "intersection") . 

20 3-7.4 Process Evr^p1;ir.p, 

A "process exception- is a programming exception 
thrown by members of the classes in this section. 
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3.7,5 Process 
15 Attribul^^fi 

age 

brand 

charges 

localPermit 
2 0 permit 

priority 
privateClasses 
regional Permi t 

Opera ti^i^lgy 
25 charge 
live 

restrict 
restricted 
sponsor 
30 wait 

A "process" is a named object that constitutes an 
autonomous computation. 
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A process' native attributes are the process' age 
(attribute "age"), brand (attribute "brand"), charges 
(attribute "charges"), local permit (attibute 
"localPertnit") , permit (attribute "permit"), priority 
5 (attribute "priority"), privately held and used classes 
(attribute "privateClasses" ) , and regional permit 
(attribute "regionalPermit") . 

A process' native operations carry out the process' 
autonomous computation (operation "live"), delay the 
10 computation for a period of time (operation "wait"), 

impose a temporary permit on the process itself (operatic: 
"restrict"), perform a procedure under a teti^orary permit 
and the resulting effective permit of the responder's 
owner (operation "sponsor"), and charge another process 
15 for services that the present process provides to the 
other process (operation "charge") . 

3.7.6 Resourcg 
Attributes 

condition 
20 conditions 

use 

A "resource" is an object about which certain 
guarantees can be made to a process throughout the 

25 process' performance of a particular procedure. 

A resource's native attributes are the resource's 
current condition (attribute "condition") and the 
identifiers of the resource's possible conditions 
(attribute "conditions") . 

30 A resource's native operation performs a certain 

procedure once the resource has made the guarantees 
requested of the resource (operation "use") . 

3-3 Agent and Place Grm^p 
Object (Referenced) 
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Authentirarnr 
Exception (Unchanged) 

• Trip ExcepM',^p 
Means 

Process (Named) 

• Agent 

• Place (Unmoved) 
TirPKet Stub 

• Ticket 
10 • Way 

Unchanaec^ 
• Interchana^f^ 
^ Unmoved 

3.8.1 Assnt 

15 Operation^ 

go 

send 

An "agent- is a process that can move from place to 
30 place. 

20 An agent's native operations transport the agent to 

one destination (operation "go") or one or more clones to 
as many destinations concurrently (operation "send"). 



3-8.2 Authenticat^ni- 

An "authenticator" is an object with which the 
25 Network can authenticate an agent that initiated a trip, 
e.g., as the agent passes between regions. 
mx^: Concrete subclasses of class "Authenticator" are 

region- specific and thus user-defined. 

3-8.3 Interchange^ 
30 Attribu^Aff 

digest 
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An "interchanged" object is an unchanged object for 
which the Network may substitute an equivalent object 
whenever the object's owner takes a trip. 

An interchanged object's native attribute is the 
5 object's digest (attribute "digest") . 



3.8.4 Means 

A "means" is an object that identifies a means, e.g., 
15 ^ particular wireless communication medium, by which the 

Network can transport an agent that initiated a trip from 
10 the trip's source, to the trip's destination, or both. 
Note : Concrete subclasses of class "Means" are 

20 region- specific and thus user-defined. 

3.8.5 Place 
Att^yirb^t^gs 

15 address 

publicClasses 

Op^r?tji,Pfig 

entering 
exiting 
20 terminate 

A "place" is a process that is the locale for zero or 
more other processes. 

A place's native attributes are the place's address 
(attribute "address") and the place's publicly held and 
25 used classes (attribute publicClasses"). 

A place's native operations pass judgment upon a 
process' proposed entry of the place (operation 
"entering"), take note of the process' exit from the place 
(operation "exiting"), and forcibly terminate an occupant 
30 (operation "terminate"), provided the requester is 
sufficiently capable (attribute "canTerminate" of the 
requester's permit) and the occupant's peer. 



50 



3.3.6 liclsfit 
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Attribueaa 

desiredWait 
destinationAddress 
des t inat ionCl as s 
5 destinationName 

des tinat ionPermi t 
maximumWait 

A "ticket- is a ticket stub that describes an 
intended trip from the viewpoint of the agent taking the 
10 trip. The ticket's main purpose is to identify the trip's 
destination. 

A ticket's native attributes are a telename 
(attribute "destinationName") and a teleaddress (attribute 
"destinationAddressa") of the destination, a citation to a 

15 class of which the destination is a member (attribute 
••destinationciass-), the local permit the agent needs at 
the destination (attribute "destinationPermit") , the time 
interval within which, ideally, the trip should be made • 
(attribute "desiredWait"). and the time interval within 

20 which, under any circumstances, the trip shall succeed or 
fail (attribute "maximumWait") . 

3.8.7 TickRt .«=!^i,|;^ 
Attrib^l^>.y 

travelNotes 
25 v*ay 

A "ticket stub" is an object that describes the 
results of a trip. 

A ticket stub's native attributes are the way back to 
the trip's origin (attribute "way") and information, 
30 present originally on the ticket, for the exclusive use of 
the agent that initiated the trip (attribute 
"travelNotes") . 

3-8.8 Trip Rvr^ph^^,^ 
Attribu^ftff 
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ticketSt;ib 

5 A "trip exception" is an exception that signifies the 

Network's failure to provide the trip that a ticket 
describes . 

S A trip exception's native attribute is the ticket 

stub (attribute " tickets tub" ) . 

3.8.9 Unmoved 
IS ^ "unmoved" object cannot be moved from one place to 

another. An unmoved object often is described as 
10 immovable. 

A reference to an unmoved object is voided if 
20 movement of the object is attempted. 

Note; Places are immovable. 



3.8.10 . Way 

15 Attribut:^? 

authenticator 

means 

name 

A "way« is an object that identifies a route along 
20 which the Network can transport an agent that initiated a 
trip. 

A way's native attributes are the name of the region 
through which the trip is to proceed (attribute "name") 
and the means (attribute "means") and the authenticator 
25 (attribute "authenticator") to be used to enter that 
region. 



3.9 Meetincp Hr-m^p 
Object (Referenced) 

• Exception (Unchanged) 

• • Meeting Exception 

• Process (Named) 

• • Place (Unmoved) 
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• • • Meeting Place 
PetitionPf;^ 

3-9-1 Meeting Except inn 

A "meeting exception" is an exception that signifies 
5 a meeting place's failure to arrange the meeting that a 
petition describes. 

3-9.2 Meeting P\f ni^ 

Qperatinriff 

meet 
part 
part All 

A -meeting place" is a place that will, arrange 
meetings between any two petitioned objects that are among 



15 



its occupants. 

A meeting place's native operations begin a meeting 
(operation "meet"), end one (operation -part"), and end 
all meetings involving the requester (operation 
"partAll » ) , 

3-9-3 PetitioT^ 
20 Attributfia 

agentClass 

agentName 

maximumWait 

A -petition" is an object that describes an intended 
25 meeting from the viewpoint of the petitioner. The 
petition's main purpose is to identify the petitionee. 

A petition's native attributes are a telename of the 
petitionee (attribute -agentName-). a citation to a class 
of which the petitionee is a member (attribute 
30 "agentClass"). and the time interval within which the 
meeting attempt shall succeed or fail under any 
circumstances (attribute "maximumWait"). 
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3.9.4 Petitioned 
Operations 

meeting 
parting 

5 A "petitioned" object, necessarily an agent, can play 

the role of either petitioner or petitionee in the 
establishment of a meeting. 

A petitioned object's native operations pass judgment 
upon a request for a meeting (operation "meeting") and 
10 take note of a parting (operation "parting"). 
Nots: Instances of no predefined classes are 

petitioned objects. 

3.10 Miscellaneous Group 
Obj ect (Referenced) 



■15- 



20 



Calendar Time 
Exception (Unchanged) 

• Programming Exception 

• • Miscellaneoua T^vf-^pti.gn 
Pattern (Ordered) 

Primitive (Executed & Unchanged) 

• Number (Ordered) 

• • Real 
Stream 

• Random Streaft) 



25 3.X0.1 Calendar Tim^ 
day 

dayOfWeek 
dayOfYear 
30 dst 
hour 
minute 
month 
second 
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15 



year 
zone 

Qp^ratiop? 

globalize 
5 localize 
normalize 

A "calendar time" is an object that identifies a 
local date and time of day to the precision of one second 
using UTC. A calendar time also records the local time 
10 zone and to what extent, if any, DST was in effect then 
and there. 

A calendar time's native attributes give the time's 
hour (attribute "hour"), minute (attribute "minute-), and 
second (attribute -second"}; the date's year (attribute 
15 "year-), month (attribute "month"), and day (attribute 
"day"); the days of the week (attribute "dayOfWeek") and 
year (attribute "dayOfYear" ) ; and, finally, the time zone 
(attribute "zone") and to what extent DST is in effect 
there (attribute "dst") . 
20 A calendar time's native operations localize 

(operation "localize"), globalize (operation "globalize"), 
or normalize (operation "normalize") the calendar time. 

35 3.10.2 Migcellaneous Evr^p^joir^ 

A "miscellaneous exception" is a programming 
25 exception thrown by members of the classes in this 
section. 
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3.10,3 Pattern 
Qperationi^ 

find 

30 substitute 

A "pattern" is an object for lexically analyzing 
strings. The pattern's text, itself a string, dictates 
the exact nature of the analysis. 
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A pattern's native operations search a string for the 
first matching substring (operation "find") or modify all 
matching substrings (operation "substitute") , 

3.10.4 Random Stream 
5 A "random stream" is a stream whose items are 

pseudo- randomly chosen integers in [0, M] . The items are 
determined by an integer—the seed--in the same interval. 
A random stream never produces its last item. in one 
embodiment of the present invention, "M" is chosen by the 
10 creator of the random stream and is specified as an 
initialization parameter. 

3.10.5 gsal 

A real is a number that constitutes a real number in 
mathematics. 

15 liQtfi: Internally the Engine may represent reals- -and 

P«3:form arithmetic operations involving 
them- -with only finite precision. Not all real 
numbers, therefore, are necessarily instances of 
this class in practice, and the results of the 
arithmetic operations, when performed by reals/ 
may be only approximate. 
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4 TgLESCRIPT CIA35 DRTayT.Q 

Telescript's predefined classes are defined, in 
alphabetical order, in this section of this appendix. . 
25 subsection is devoted to each class. 

4.1 Conventions 

A class' definition begins with a diagram of the 
portion of the class graph that encompasses that class. 
The class itself is underlined. 
30 The following sections follow as necessary in the 

discussion of each predefined class. 
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Class 

This section describes the class apart from the 
class' features. The class is formally defined following 
the conventions of Section 6, but an ellipsis (...) 
5 appears in place of the formal definitions of the class' 
features. Described in prose is how, if at all, the 
class' interface's encoding is parameterized (see Section 
6 below) , 

CQRstrugtAgn 

10 This section describes operation "initialize" as it 

pertains to members of the class. If this section is 
omitted, a particular description is implied as described 
below in Section 6. 

Subclasses 

15 This section comprises the definitions of the class' 

predefined immediate subclasses. This section is omitted 
iff the class is not a subclass of class "Exception" or is 
a subclass of class "Exception" but has no predefined 
subclasses . 

20 At:t;rit?Mt;gg 

These sections define the attributes native to the 
class. Separate sections are devoted to pxiblic, private, 
internal, and other system attributes of the class itself 
and instances of the class. A section is omitted iff it 
25 would be empty. 

An attribute is formally defined following the 
conventions of Section 6. The attribute's semantics and 
exceptions are informally defined in prose. 

30 These sections define the operations native to the 

class in the same way that other sections, described, 
define the attributes native to the class. 
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If an operation modifies the stack that holds its 
arguments and result, the operation's effect upon the 
stack is described assuming the arguments have been popped 
from the stack and any result has yet to be pushed onto 
5 the stack. 

Ad^pt^tipns 

This section describes how the class implements 
features that the class inherits. This section is omitted 
iff the class implements no such features. 

10 Conversions 

This section describes the conversions that produce 
instances of the class. This section is omitted iff there 
are no such conversions. 

The definition of an individual conversion identifies 
15 a source class and states how the source class' members 
are converted to the subject class. If not all members 
can be so converted, which can be converted are indicated. 
If the source class of one conversion is a subclass of the 
source class of another, the former conversion takes 
20 precedence over the latter. Conversions are not chained. 
Notfe; Conversion is done, i.e., in a single step. 

Thus the conversion of a telenumber to an octet 
string, e.g., is undefined, even though the 
conversion of a telenumber to a string and the 
conversion of a string to an octet string are 
defined. 

4.2 Aqerit 
Object (Referenced) 
• Process (Named) 
30 • • Agent 

Agent : 
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abstract interface (Process) . (...),- 
Pyj,vate TnBt-ance ODgrg|^^r.^o 

unprotected op (ticket: copied Ticket) TicketStub 
throws PermitViolated, Statelmproper. TripException; 

Transports the responder to the destination 
identified by the ticket (argument "ticket") subject to 
the ticket's other terms. The operation returns the 
ticket stub. 

10 An exception is thrown if the responder holds a 

permit that forbids operation -go" ("PermitViolated"), the 
responder's state precludes operation "go* 
("Statelmproper"). or the trip failed ("TripException"). 

send ■• 

IS unprotected op (tickets: copied List [Ticket]) 

TicketStub j Nil 

throws PermitViolated, Statelmproper, 
TripException; 

Transports a clone of the responder to the 
20 destination identified by each and every listed ticket 
(argument "tickets") subject to the ticket's other terms 
The responder's allowance is reduced by the amounts the 
tickets assign to the clones. The operation returns a nil 
for the responder, a ticket stub for each clone. 
25 If a member of either class "Permit Violated- or 

class "State Improper" causes the operation to fail, the 
responder experiences the failure, no clones having been 
created. Otherwise, the responder experiences the 
operation's, success, and each clone, separately and 
30 independently, experiences either the operation's success 
or Its failure because of a member of class "Trip 
Exception" . 
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An exception is thrown if the responder holds a 
permit that forbids operation "send" or whose allowance is 
less than the sum of those of the permits on the listed 
tickets ("PermitViolated") , the responder's state 
5 precludes operation "send" ( "Statelmproper" ) , or the trip 
failed ("TripException") . 



4.3 Association 

Object (Referenced) 
• Association (Ordered) 

10 qt^gs 

Association: 

sealed interface [keyClass, valueClass: Class] 
(Object, Ordered) = (...); 

25 Parameterized by the classfts of which the key 

15 (argument "keyClass") and the value (argument 

"valueClass") of each member of the subject class are 
themselves members . 



Construction 

20 unprotected op (key: keyClass; value: valueClass); 

Makes the responder's native attributes the 
like -named arguments (argument "key" and argument 
"value") . 



Public Instance At^.7^^hll^^« 
25 kev: 
^ keyClass; 

The responder's key. 
so value : 
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valueClass; 

The responder's value. 
Adaptation^ 

5 One association is after another according to their 



keys. 



keys 



isBefore 

One association is before another according to their 



10 isgqVftl 

Two associations are equal according to their keys. 

4.4 Attribute 
Object (Referenced) 
• Feature 
15 • • Attribute 



Attribute. 

sealed interface (Feature) »(...); 

20 initialize. 

xinprotected op ( 

constraint; Constraint | Nil ; 
isSet, isPublic: Boolean! Nil ; 
exceptions: Set [Identif ier ! ) (Nil) ; 

25 Makes the responder's attributes the like-named 

arguments (arguments "constraint", "exceptions", 
so "isPublic", and "isSet") . If an argument is a nil, 

however, the corresponding attribute is made a constraint 
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with nils as initialization parameters, a cleared set, 
"false" or "false", respectively. 

Public Instance Attributi ng 
constraint : 
5 Constraint; 



The constraint upon the attribute that the responder 
defines . 



Boolean; 



10 Whether the attribute that the responder defines is 

not read-only. 

25 Adaptat;;i,o^g 
iggqya^A 

Two attribute definitions are equal according to 
15 their attributes native to feature definitions and 
^ attribute definitions. 

4.5 Authentlcar_9Y 
Ob j ect (Referenced) 
• Authentication 



20 Class 
40 Authenticator : 

abstract interface () ; 

4.6 ait 
^ Object (Referenced) 

25 • Primitive (Executed & Unchanged) 
• • lit (Ordered) 



50 



Claqs 
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Bit; 

5 sealed interface (Primitive, Ordered) = () ; 

Adaptations 
AgAftQy 

5 One bit is after another iff the first is one, the 

second zero. 

isBefore 

TO 

One bit is before another iff the first is zero, the 
second one. 

20 10 isEoual 

Two bits are equal iff both are zero or one. 

A bit string having one item produces a bit that 
15 equals that item. 

30 

Boolean 

The booleans false and true produce zero and one, 
respectively. 

35 

Character 

20 The numerals zero (0) and one (1) produce zero and 

^ one, respectively. 

Integer 

The integers zero and one produce zero and one, 
45 respectively. 

25 Octet 

An octet all of whose bits except Bit 0 are zero 
^ produces that bit. 
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octetstirxm 

An octet string that can be converted to an octet 
that can be converted to a bit produces that bit. 

5 string that can be converted to a character that 

can be converted to a bit produces that bit. 

4.7 Bit Strinqt 
Object (Referenced) 

• Collection 

10 • • List (Ordered) 

• • • Constrained List (Constrained) 

• • • • Bit str-ir^r, (Executed) 

Clagg 

BitStrinq; 

15 sealed interface (ConstrainedList [Bit], Executed) . 

\ • • • J / 



initi^ii,z^x 

unprotected op (segments: Object 

/* Bit (protected BitStringi */) ; 



20 



Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right. 

Mapt;arlonfi 
^5 Con3traj,nt 

The attribute is sealed, its "ofClass-, "classld- 
"xslnstance". "iaOptional " . and -passage" attributes ar^ 
class "Bit", the identifier of class "Bit", "true- 
-false", and "byCopy", respectively. 
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One bit string is after another as if enough "zero" 
bits were first prepended to the shorter bit string to 
make the shorter bit string equal in length to the longer 
5 bit string. 

One bit string is before another as if enough "zero" 
bits were first prepended to the shorter bit string to 
make the shorter bit string equal in length to the longer 
10 bit string. 

Converaionfl 

ait 

A bit produces a bit string whose only item equals 
that bit . 

A boolean produces the result of first converting the 
boolean to a bit, and then converting the bit to a bit 
string. 



Character 

35 20 A character produces the result of first converting 

the character to an octet string, and then converting the 
octet string to a bit string. 

^ Tpt^gq^r 

An integer in the range of [^2\ 2"), for some integer 
25 "n" and none smaller, produces a bit string of length "n" . 
^ A twos' complement representation is used. The bit at 

position one represents -2°. The bit in each position "i" 
in the range of (l, n] represents 2-'. 

so 2£t££. 
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An octet produces the result of first converting the 
^ octet to an octet string, and then converting the octet 

string to a bit string. 

OctetStrj, nq 

to 5 An octet string whose length is "n" produces a bit 

string whose length is "8n". The bit whose position in 
the bit string is (8i+j) is Bit O-j) of the octet whose 
position in the octet string is "i". in the above, "i" 

^5 and "j" are integers, "i» is in the range [0, n) , and »j" 

10 is in the range [1, 8] . 
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String 

A string produces the result of first converting the 
string to an octet string, and then converting the octet 
string to a bit string. 

15 4.8 Boolean 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Boolean (Ordered) 



Class 

35 20 Boolean: 

sealed interface (Primitive, Ordered) = (...); 



Public Instance On^i^^ti? V^ff 
an^ 

op (boolean: Boolean) Boolean; 

^ 25 Returns the logical conjunction of the boolean 

(argument "boolean") and the responder. 



not : 

op () Boolean; 
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Returns the logical negation of the responder. 

op (boolean: Boolean) Boolean; 

Returns the logical disjunction of the boolean 
5 (argument "boolean") and the responder. 

isAftey 

One boolean is after another iff the first is "true", 
and the second is "false". 

One boolean is before another iff the first is 
"false", and the second is "true". 

jsEquat 

Two booleans are equal iff both are "false" or both 
30 15 are "true". 

Conversions 
Bit 

A bit produces an indication of whether the bit is 

one. 
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20 Character 

A character produces an indication of whether the 
character's Unicode code is non-zero. 

Collgrfinn 

A collection produces an indication of whether the 
25 collection's length is non-zero. 

50 

Exception 

An exception produces "true". 

55 
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Nil 

A nil produces "false". 
Number 

A number produces an indication of whether the number 



10 5 is non-zero. 



Octet 

An octet produces an indication of whether any of the 
octet's bits is one. 

4.9 Calendar Time 
10 Object (Referenced) 
• Calendar Time 



Class 

2s CalendarTime; 

interface »(..,); 

15 Construction 

Makes the responder's native attributes nils. 



Public Instance At tributeg 
dav: 

20 Integer|Nil; 

Either the day of the month the responder identifies 
or a nil. 



davOfWeek; 
45 readonly Integer] Nil; 

25 Either the day of the week the responder identifies 

or a nil. 

50 
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davOfYear: 

readonly Integer|Nil; 

Either the day of the year the responder identifies 
or a nil. 



15 5 dst : 

Integer j Nil; 



Either the seasonal offset in minutes, from the 
permanent offset, of the time zone the responder 
identifies or a nil. 

10 hour: 

Integer! Nil; 

Either the hour of the day the responder identifies 
or a nil. 

mii^vt;^:. 
15 Integer I Nil; 

Either the minute of the hour the responder 
identifies or a nil. 

Integer I Nil; 

^ 20 Either the month of the year the responder identifies 

or a nil. 



so 
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Integer I Nil; 

Either the second of the minute the responder 
identifies or a nil. 



Integer I Nil; 

Either the year in the Gregorian calendar the 
responder identifies or a nil. 



10 Integer I Nil; 



Either the permanent offset in minutes, from UTC, of 
the time zone the responder identifies or a nil. 



PubJ-ic Instance Operation.*^ 
globalize ; 
30 15 unprotected op () ; 

Sets the responder' s permanent and seasonal offsets 
to those of UTC so that the absolute point in time 
identified is unchanged. 

localize: 
20 unprotected op (); 

40 

Sets the responder' s permanent and seasonal offsets 
to those of the current place so that the absolute point 
^ in time identified is unchanged. 

25 unprotected op () Boolean; 

so 
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Normalizes the responder and returns an indication of 
whether any of the responder' s attributes were altered in 
the process. 

Adaptationa 
5 Asgquaj, 

Two calendar times are equal according to their 
native attributes. 

10 A time produces a normalized calendar time that 

identifies the same absolute point in time and the same 
permanent and seasonal offsets • 

4,10 Cased 
Cased 

15 Class 



abstract interface () « {...)/ 



Public TnstancP ^ ttribuf;g g 
35 isLower: 

20 abstract readonly Boolean; 



Whether any item of the responder is lower-case, 
abstract readonly Boolean; 

Whether any item of the responder is upper-case. 



25 Public Inntance Op^i^^f-j 
50 makeLower = 

abstract op () copied Cased; 
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Returns a copy of the responder in which every 
^ upper-case item has been replaced with the item's 

lower-case equivalent. 

maK^IJpp^r ; 

10 5 abstract op () copied Cased; 

Returns a copy of the responder in which every 
lower-case item has been replaced with the item's 
upper- case equivalent. 



15 



4-11 Character 
20 10 Object (Referenced) 

• Primitive (Executed & Unchanged) 

♦ • Char^Ctec (Cased & Ordered) 



25 



30 
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Class 

Character: 

15 sealed interface (Primitive, Cased, Ordered) - ()/ 

Adaptations 
isAftQi: 

One character is after another according to their 
Unicode codes, 

20 i^^Befoy^ 

One character is before another according to their 
Unicode codes. 

Two characters are equal according to their Unicode 
25 codes. 



Cpnveargiong 

ait 
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The bit "zero" produces the numeral zero (0), and the 
^ bit one produces the numeral one (1) . 

Integer 

An integer in the range of (0, 65535] produces the 
10 5 character with that Unicode code. 

Octet 

An octet produces the result of first converting the 
octet to an integer, and then converting the integer to a 
character. 

An octet string produces the result of first 
converting the octet string to an integer, and then 
converting the integer to a character. 

String 

A string having one item produces a character that 
equals that item. 

Ci,tatjL<?R 
Object (Referenced) 
35 • Citation (Ordered) 



25 



40 
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20 Clas^ 

Citation; 

interface (Object, Ordered) = (.,.); 

Construct i^9n 

initiali2g>; 

25 unprotected op { 

title: Identifier!; author: Telename|Nil; 

majorEdition, minorEdition: Integer | Nil) ; 
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Makes the responder's native attributes the 
like-named arguments (arguments "author", "majorEdition" , 
"minorEdition" , and "title"). 

Public Instance Attributes 
10 5 author; 

Telename jNil; 



15 
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Either the telename of the author identified by the 
responder, if the latter is assigned or such a constraint 
is imposed, or a nil, otherwise. 

10 maiorEdition; 

Integer I Nil; 

Either the number of the major edition identified by 
the respdnder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

15 minorEdition: 
Integer I Nil; 

Either the number of the minor edition identified by 
the responder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

20 U£i^ 

Identifier! ; 

The identifier of the title the responder identifies. 

Adaptations 
isAfter 

25 One citation is after another iff their "author" 

attributes are peers, their "title" attributes equal, and 
the first- citation's "majorEdition" attribute is after 
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the second citation's "majorEdition" attribute or the 
"majorEdition" attributes of both citations are equal and 
the first citation's "minorEdition" attribute is after the 
second citation's. 

5 isBefnT->> 

One citation is before another iff their -author" 
attributes are peers, their "title" attributes equal, and 
the first citation's "majorEdition" attribute is before 
the second citation's "majorEdition" attribute or the 
10 "majorEdition- attributes of both citations are equal and 
the first citation's "minorEdition" attribute is before 
the second citation's. 

isEoual 

Two citations are equal iff their "author" attributes 
15 are peers and their other native attributes are equal. 

4.13 Citfid 

Cited 

Class 

20 abstract interface ()-(...); 

Constnirr-j,7n 

initiallaer 

unprotected op (title: Identifier!; 

majorEdition, minorEdition: Integer); 

25 Makes the responder'a native attribute a citation 

whose "author" attribute is the current process' assigned 
telename and whose other attributes are the like-named 
arguments (arguments "majorEdition". -minorEdition", and 
"title") . 
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Public Instance ;^f_f_ri^n^^a 
citation: 

readonly protected Citation; 

The responder's assigned citation. 

5 4.14 Class 

Object (Referenced) 

• 5LUaa (Cited & Interchanged) 

Clsig? 

Class ; 

10 sealed interface (Object, Cited, Interchanged) = 

(...); 

Const rugr4i;7n 

initialize i 

unprotected op () 

15 throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable"). 
Not£: A class is created using operation 
"makeClasses", not operation "new". 

?yl?liC Instance Operatinnc, 
20 convert = 

sealed op (source: protected Object) copied Object 
throws ConversionUnavailable; 



Returns either the instance of the responder produced 
45 by converting the object (argument "source-) to that 

25 class, if the object is not already an instance of that 
class, or a copy of the object, otherwise. 

The operation looks for a conversion method first in 
^ the source class and then, failing that, in the 

destination class. An exception is thrown if the object 
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10 



cannot be converted as requested 
("ConversionUnavailable") . 

Uo^i The two steps permit either the source or the 

destination class, whichever was defined later, 
5 to implement the method for a particular 

conversion. 

sealed op (instance: protected Object) Boolean; 

Returns an indication of whether the object (argument 
10 "instance") is an instance of the responder. 

isMember: 

sealed op (member: protected Object) Boolean ; 

25 Returns an indication of whether the object (argument 

"member") is an interface, but not necessarily an 
15 implementation, member of the responder. 

30 ip$vib<?),^gg; 

sealed op (subclass: Class) Boolean; 



20 
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Returns an indication of whether the class (argument 
"subclass") is a subclass of the responder. 

20 new: 

sealed op (parameters: Object ...) Object 

throws ClassAbstract, Exception, ObjectUninitialized; 

Returns the new instance of the responder determined 
by the initialization parameters (argument "parameters"). 
25 The signature above notwithstanding, the operation's 

signature is that of operation "initialize" as defined by 
the responder. 



55 



202 



BNSDOCID: <EP__0634719A2_L> 



EP0634 719 A2 



10 



15 



20 



25 



30 



35 



40 



45 



An exception is throvm if the responder is abstract 
("ClassAbstract") , a class-specific problem is encountered 
{"Exception"), or the potential object uses its own 
features { "ObjectUninitialized" ) . 

5 4,15 Class Definition 
Ob j ect { Referenced) 
• Class Definitiioq 

10 sealed interface = (..,); 

cgngtyy^tAgn 

iyij,t:iali,2;^; 
unprotected op ( 

title: Identifier! ; 
15 majorEdition, minorEdition: Integer; 

interface: Interface; 

implementation: Implementation] Nil) ; 

Makes the responder' s native attributes the 
like-named arguments {arguments "implementation", 
20 "interface", "majorEdition" , "minorEdition", and "title"). 

Public Instance Attribuhf^a 
implementation- 
Implementation j Nil; 

Either the implementation of the class the responder 
25 defines, if there is an implementation, or a nil, 
otherwise. 



interface: 
50 Interface; 
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The interface of the class the responder defines. 

maiorEdition: 
Integer; 

The "majorEdition" attribute of the assigned citation 
5 of the class the responder defines, 

minorEdition: 
Integer; 

The "minorEdition" attribute of the assigned citation 
of the class the responder defines. 

10 title; 

Identifier! ; 

The "title- attribute of the assigned citation of the 
class the responder defines. 

Public Instance ODerat ^ ^ ^g 
15 makeClasses : 

op (definitions: protected ClassDefinition ...) 

Lexicon [Class] 
throws ClassException; 

Returns a lexicon of the classes the responder and 
20 the other class definitions (argument "definitions") 

define collectively. Each value is the class whose title 
equals the associated key. 

A citation is assigned to each class as follows. The 
assigned citation's "author" attribute is the current 
25 process' assigned telename . The assigned citation's other 
attributes are as defined by the class' class definition. 

An exception is thrown if the classes cannot be 
created ("ClassException"), 
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Adaptations 
5 isEqual 

Two class definitions are equal according to their 
native attributes. 

5 4.16 Class Exceptioi^ 
Object (Referenced) 

• Exception (Unchanged) 

^5 • • Programming Exception 

• • • Class Exception 

10 Class 
20 CXa3?E;pcceptiQAr 

abstract interface (ProgrammingException) = (} ; 



25 



Subclasses 

ClassSealed: 
15 interface (ClassException) » (); 

30 A proposed new class has an immediate superclass that 

is sealed. 
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ClaasUndefinRd- 

interface (ClassException) « {) ; 

20 A proposed new class uses an undefined class 

identifier. 

FeatureR edefine^; 

interface (ClassException) = () ; 

A proposed new class and one of its interface 
25 superclasses have native features denoted by the same 
identifier. 

Feature5f*a1^H. 
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interface (ClassException) = (); 



A proposed new class implements a feature sealed by 
one of the class' interface superclasses. 



10 



5 



FeatureUndefined; 

interface (ClassException) » () ; 



15 



A proposed new class uses an undefined feature 
identifier. 



20 



MixinPisallowgd- 

interface (ClassException) - ()/ 



10 



A proposed new class uses a mix-in where a flavor i 



xs 



required. . 



25 



SuperclassesInvaliH . 

interface (ClassException) » (}; 

A proposed new class has immediate superclasses that 



15 are inconsistent. 

4.17 Collection 
Object (Referenced) 
• Collect inn 

Clasfl 
20 Collect^ioT^; 

interface [itemClass : Class] « (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

25 Construg^inTT^ 
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unprotected op (items: itemClass ...) throws 
Itemlnvalid; 

Makes the reaponder's items the objects (argument 
S "items") . 

An exception is thrown if a proposed item is invalid 
("Itemlnvalid") . 

Public Instance Attribute^ 
length; 
10 readonly Integer; 

The responder's length. 

Public Instance O perations 

unprotected op () ; 

15 Removes from the responder and discards all of its 

items. 

No£s: The operation reduces the responder's length to 

zero. 

ex^mjqg ; 

20 op (item: protected itemClass) itemClass | Nil; 

Either leaves in the responder and returns an item 
that equals the object (argument "item"), if there is at 
least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
25 undefined. 

exclude: 

unprotected op (item: protected itemClass) 
itemClass |Nil; 
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Either excludes from the responder and returns an 
item that equals the object (argument "item"), if there is 
at least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
5 undefined. 

in<?3-vi<^g ; 

unprotected op (item: itemClass) throws Itemlnvalid; 

Includes the object (argument "item") in the 
responder as a new item. 
10 An exception is thrown if the proposed item is 

invalid as such ("Itemlnvalid") , 

gtrg^tn;. 

op 0 copied Stream [itemClass] ; 



Returns a stream whose items are those of the 
15 responder. A subclass of class "Collection" can define 
the order in which the stream produces the responder' s 
items, but class "Collection" leaves the order undefined. 

If the responder is changed after the stream is 
created, the stream produces newly included items iff the 
20 stream would not have produced them earlier and does not 
produce newly excluded items unless the stream did so 
earlier. 

HfitS: The subclass of class "Stream" of which the 

^ stream is an instance is undefined. 

25 Adaptations 

45 Two collections are equal iff their lengths are equal 

and their items can be paired so as to make the items in 
each pair equal. A subclass of Collection can narrow, but 
30 not broaden, this definition of equality. 

50 
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4 , 18 Collection Except^ip q 
Obj ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 
5 • • • Collecti on Except^if yr^ 

Class 

CollectionException ; 

abstract interface (ProgrammingExcept ion) = () ; 

Subc;a??eg 
10 ItemDuplicated: 

interface (CollectionException) » (); 

One proposed item of a set equals another. 

25 It^mlTiv^Xj^d; 

interface (CollectionException) » () ; 
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15 A collection's proposed item does not satisfy the 

collection's constraint. 



35 interface (CollectionException) = () ; 

One proposed key of a dictionary equals another. 



20 Kevlnvalidr 

interface (CollectionException) » (); 

45 A dictionary's proposed key does not meet the 

dictionary's constraint, or an object purporting to equal 
a key in a dictionary does not. 



25 Obiectau npaired: 

interface (CollectionException) = {) ; 
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Supposedly paired keys and values of a dictionary are 
odd in number. 



Pogitionlnvalid; 

interface (CollectionException) » () ; 

5 An integer purporting to equal a position in a list 

or a procedure does not. 

StackPepleted; 

interface (CollectionException) - (); 

The length of a stack prevents the stack's 
10 manipulation as requested. 



4.19 Constrained 
25 Constrained 



Class 

15 abstract interface () . (...); 



Construct inn 

initialize; 

unprotected op (constraint: copied Constraint [Nil ) ; 

Makes the responder's native attribute either the 
20 constraint (argument -constraint"), if not a nil, or one 
with nil initialization parameters, otherwise. 

Public Instance At;t;r? >^Mt;'"? 
^ constraint ^ 

readonly protected Constraint; 



50 



25 The constraint upon nominated properties of the 

responder . 
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4.20 Congtrained Diet i<;;>nf^^ 
Ob j ect { Referenced) 

• Collection 

• • Set 

5 • • • Dictionary 

• • • • Constrained Dictionary (Constrained) 

ConstrainedPictionary ; 
interface [keyClass, valueClass: Class] 
10 (Dictionary [keyClass, valueClass] , Constrained) 

» (...); 



Parameterized by the classes of which the key 
(argument "keyClass") and the value (argument 
25 "valueClass") of each item of each member of the subject 

15 class are themselves members. 



Construction 

initialize; 

unprotected op (constraint: copied Constraint; 
keysAndValues : Object 
20 /* key: keyClass ; value: valueClass */) 

throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 

Makes the responder's items associations between the 
key-value pairs (argument "keysAndValues") and the 
25 responder's "constraint" attribute the constraint 
(argument "constraint") . 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated") , a proposed key is invalid as such 
("Keylnvalid"), or the number of objects is odd 
50 30 ("ObjectsUnpaired") . 
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add 

Only a key satisfying the constraint will be 
included. 

The constraint is upon the keys. 

15 include 

Only a key satisfying the constraint will be 
included. 
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10 rekey 

Only a key satisfying the constiaint will be 
included. 

set 

Only a key satisfying the constraint will be 
15 included. 

4.21 Constrained List 
Ob j ect (Referenced) 

• Collection 

• • List (Ordered) 

20 • • • Constrai ned List (Constrained) 

Cpngt^raini?<ai^igt;:, 

interface [itemClass: Class] 

(List [itemClass], Constrained) = (...); 

25 Parameterized by the class (argument "itemClass") of 

which each item of each member of the subject class is 
itself a menf±)er. 
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initi,^;,i,ze? 

5 unprotected op (constraint: copied Constraint; 

items : itemClass . . . ) 
5 throws Itemlnvalid; 

10 

Makes the responder's items the objects (argument 
"items"), their positions increasing from left to right, 
and the responder's "constraint" attribute the constraint 
is (argument "constraint") . 

10 An exception is throvm if a proposed item is invalid 

("Itemlnvalid") . 



20 
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Adaptations 

Only an object satisfying the constraint will be 
15 included, 

qpnstiy^Ant 

The constraint is upon the items . 
include 

Only an object satisfying the constraint will be 
20 included. 

4.22 Constrained Sr^ 
Object (Referenced) 

• Collection 

• • Set (Verified) 

25 • • • Constrained c;^^ (Constrained) 

Class 

ConstrainedSet 

interface [itemClass : Class] 

(Set [itemClass], Constrained) =»(...); 
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Parameterized by the class (argument "itecnClass") of 
5 which each item of each member of the subject class is 

itself a member. 

5 initialize: 

unprotected op (constraint: copied Constraint ; 
items: itemClass , . . ) 
throws rtemDuplicated, Itemlnvalid; 

Makes the responder's items the objects (argument 
10 "items") and the responder's constraint attribute the 
20 constraint (argument "constraint"). 

An exception is thrown if two proposed items are 
equal ( " ItemDuplicated" ) or a proposed item is invalid as 
such ("Itemlnvalid") , 

25 

15 Adap^^tAgng 

constraint 

3Q The constraint is upon the items. 

i^<?^^dg 

Only an object satisfying the constraint will be 
^ 20 included. 

4.23 CQptgty^j^^t 
Ob j ect (Referenced) 
• Constraint 



40 



Class 

46 25 Constraint z 

interface « (...); 



so 
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Const; ryctzign 

initialize; 
unprotected op 
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(classld, passage: Identifier! |Nil; 
isOptional, islnstance: Boolean! Nil) 
throws Passage Invalid / 

Makes the responder's "ofClass" attribute a nil and 
5 the responder's other native attributes the like-named 
arguments (arguments "classld", "islnstance", 
"isOptional", and "passage"). If an argument is a nil, 
however, the corresponding attribute is made the 
identifier of class "Object", "false", "false", or 
10 "byRef", respectively. 

An exception is thrown if the proposed passage is 
20 invalid as such ( "Pas sage Invalid" } . 

Public Instance Attribut^ff 
claaald; 
15 Identifier!; 



25 
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The identifier of the class of which the responder's 
subject shall be a member. The identifier is interpreted 
according to the "vocabulary" attribute of the interface 
or implementation that provides the responder's context. 



20 islnstangfi* 
Boolean; 



Whether the responder's subject shall be an instance, 
not just a member, of the class that the "classld" 
attribute denotes. 

25 ^ isODtional. 
^ Boolean; 

Whether the responder's subject is permitted to be a 
^ nil, the "classld" attribute notwithstanding. 
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readonly Class | Nil; 

If not a nil, the class of which the -rssconder ' 
subject shall be a member. 

S passage; 

Identifier! 

throws Pasaagelnvalid; 

The identifier denoting how the reaponder's subjec 
shall be passed. 

10 An exception is thrown if the proposed p^.s sage is 

invalid as such ("Passagelnvalid'') , 

Two constraints are equal accc-dir.g tc cheir native 
15 attributes, 

4.24 Cpntagt 
Object (Referenced) 
• Contact 

Class 
20 Contact : 

interface « (...); 

initialigfi- 

unprotected op (subject: Process j. Mil; 
25 sxibjectNotes: Object|Nil; ; 

Makes the responder's "subject^ and "subjactNotss" 
attributes the like-named arguments (argumants " subject " 
and "subjectNotesV respectively) c-nd the resFondsr s 
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Other native attributes either descriptive of the subject, 
if the "subject" attribute is a process, or a nil. 



otherwise , 



10 



5 



Public Instance Attributes 
subject : 
Process I Nil; 



The responder's subject or a nil. 



15 



subiectClass: 

readonly protected Citation | Nil ; 



20 



10 Either the assigned citation of the class, which is a 

subclass of class "Agent" or class "Place", of which the 
responder's subject is an instance, if the "subject" 
attribute is a process, or either that class or a nil, if 
the "subject" attribute is a nil. 

15 subiectName: 

readonly protected Telename |Nil; 

Either the assigned telename of the responder's 
subject, if the "subject" attribute is a process, [or that 
telename] or a nil, otherwise. 

20 subiectNQtgfl. 
Object|Nil; 

An object maintained by the responder's observer. 



45 



50 
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isEoual 

Two contacts are equal according to their 
"subjectName" attributes. 
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4.25 Contacted 
Contacted 

Contacted: 
5 abstract interface () =- (.,.)/ 

CQngt;yM?ti<?n 

initialize 

Clears the responder's "contacts" attribute, 



Private Instance At trihi^t- 
20 10 contacts: 

readonly Set [Contact] ; 



The set of contacts that the responder maintains. 



4.26 Dictionary 
Object (Referenced) 
30 15 • Collection 
• Set 

• • • DictionaiTy 
^ . Cl^SS 

DictirQng^yy? 

20 interface [keyClass, valueClass: Class] 

40 (Set [Association [keyClass, valueClass]]) 

(.,.); 



Parameterized by the classes of which the key 
(argument "keyClass") and the value (argument 
25 "valueClass") of each item of each member of the subject 
class are themselves members. 

Construct -1911 

initializA- 
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unprotected op (keysAndValues : Object ... 

/* key: keyClass; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 
Ob j e c t sUnpa i r ed ; 

5 Makes the responder's items associations between the 

key-value pairs (argument "keysAndValues") . 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated") , a proposed key is invalid as such 
("Keylnvalid"), or the number of objects is odd 
10 ("ObjectsUnpaired") . 

2^ Pub^i,? ingt^nce Qpgr^tAmg 

add: 

unprotected op (key: keyClass ; value: valueClass) 
throws Keylnvalid; 

25 

15 Includes in the responder a new association, one that 

involves the first object (argument "key") as the 
associations' key and the second (argument "value") as the 
association's value. 

An exception is thrown if the proposed key is invalid 
20 as such or equals the key in an association that the 
35 responder already includes ("Keylnvalid"), 

drop; 

unprotected op (key: protected keyClass) valueClass 
throws Keylnvalid; 

25 Excludes from the responder and discards the 

association whose key equals the object (argument "key"), 
and returns the association's value. An exception is 
thrown if the asserted key is invalid as such 
("Keylnvalid"), 

30 fis^ 



40 
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op (value: protected valueClass) keyClass | Nil ; 

Leaves in the responder the association whose value 
equals the object (argument "value"), and returns the 
association's key. if the responder includes several such 
5 associations, the one selected is undefined. If the 
responder includes none, a nil is returned, 

op (key: protected keyClass) valueClass 
throws Key Invalid ; 

10 Leaves in the responder the association whose key 

equals the object (argument "key"), and returns the 
association's value. 

An exception is thrown if the asserted key is invalid 
as such ( "Key Invalid" ) . 

15 rekey: 

unprotected op (currentKey: protected keyClass; 

newKey: keyClass) 
throws Key Invalids- 
Leaves in the responder the association whose key 
20 equals the first object (argument "currentKey"), discards 
that association's key, and substitutes for that key the 
second object (argument "newKey"). The operation achieves 
this as if by means of operations "drop" and "add". 

An exception is thrown if the asserted or proposed 
25 key is invalid as such or the latter equals the key in an 
association that the responder already includes 
("Key Invalid") . 



set : 

50 unprotected op (key: protected keyClass; value: 

3 0 valueClass) 
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throws Keylnvalid; 

5 

If the responder includes an association whose key 
equals the first object (argument "key"), substitutes for 
that association's value the second object (argument 
10 5 "value") . Otherwise, includes in the responder a new 

association, one that involves the first object (argument 
"key") as the association's key and the second (argument 
"value") as the association's value. 

An exception is thrown if the proposed key is invalid 
10 as such ("Keylnvalid"). 

unprotected op (keyl, key2 : protected keyClass) 
throws Keylnvalid; 
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Transposes the responder' s values for the two keys 
15 (arguments "keyl** and "key2") . 

An exception is thrown if an asserted key is invalid 
as such ("Keylnvalid"). 

include 

20 Only an association is included. An association is 

included as a new item after excluding and discarding any 
existing item equal to the association. 

Two dictionaries are equal only if their like-keyed 
25 values are equal. 

4.27 Exception 

Object (Referenced) 

• Exception (Unchanged) 

Class 
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5 Except Aoyi: 

abstract interface (Object, Unchanged) - (..J; 

EubXic Instance QpfiT-;:^^ i r>;^;^ 
10 throw: 

5 sealed op () ; 

Finishes the current method's performance by causing 
15 the method to fail because of the responder. 

Adaptationfl 

^ 10 Two exceptions are equal iff they are instances of 

the same class. 



25 
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4.28 Executed 
Executed 

Class 
15 Ex?9utedL 

abstract interface () « (); 

This class is sealed. 



Public Instance Operate 19^^^ 

20 sealed op (exception: Class) Exception|Nil 

40 throws Exceptions- 

Performs the responder, returning either a nil, if 
the responder succeeds, or the exception causing the 
responder to fail, if the exception is a member of the 
25 supplied class (argument "exception"). The responder gets 
access to the requester's frame and properties, rather 
than the responder' s. 



50 
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An exception is thrown if the responder throws an 
exception that is not a member of the supplied class 
("Exception") . 

HaLa: The class should be Exception or a subclass 

5 thereof. 

sealed op () 

throws Exception; 

Performs the responder. The responder gets access tc 
10 the requester's frame and properties, rather than the 
responder' s. 

An exception is thrown if the responder does so 
( "Exception") . 

25 ^itl^^r: 

15 sealed op (false: Executed; precondition: Boolean) 

throws Exception; 
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Performs either the responder, if the precondition 
(argument "precondition") is true, or the executed object 
(argument "false"), otherwise. The selected executed 
20 object gets access to the requester's frame and 
properties, not the responder' s. 

An exception is thrown if the selected executed 
object does so ("Exception") . 

ILL 

25 sealed op (precondition: Boolean) 

throws Exception; 

Performs the responder iff the precondition (argument 
"precondition") is "true". The responder gets access to 
the requester's frame and properties, not its own. 
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10 



15 



20 



An exception is thrown if the responder does so 
("Exception") . 

loOP: 

sealed op () 
5 throws Exception; 

Performs the responder an indefinite number of times, 
throwing the exception, rather than proceeding, if the 
responder ever fails. The responder gets access to the 
requester's frame and properties, rather than the 
10 responder' s. 

An exception is thrown if the responder does so 
("Exception") ... 

sealed op (repetitions: Integer) 
15 throws Exception; 

30 Performs the responder the requested number of times 

(argument "repetitions"), throwing the exception, rather 
than proceeding, if the responder ever fails. If the 
integer is negative, the operation has no effect. The 
20 responder gets access to the requester's frame and 
properties, rather than the responder' s. 

Before each performance of the responder, the 
^ operation pushes onto the stack an integer that is one 

plus the number of prior performances. 
25 An exception is thrown if the responder does so 

("Exception") . 

Natfi: The operation pops none of the integers the 

operation pushes onto the stack. 



35 
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so 



55 



While: 

30 sealed op (precondition: Executed) 

throws Exception, Resultlnvalid, ResultMissing; 
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Repeatedly performs the executed object (argument 
"precondition"), pops a boolean from the stack, and, iff 
the boolean is true, performs the responder. If the 
boolean is ever false, the operation succeeds. If either 
5 executed object ever fails, the operation throws the 

exception, rather than proceed. The executed objects are 
given access to the requester's frame and properties, 
rather than the responder' s. 

An exception is thrown if either executed object does 
10 so ("Exception"), the object that would have been popped 
is not a boolean ( "Result Invalid" ) , or there is no object 
on the stack to be popped then ( "ResultMissing" ) . 

4,29 Execution Except ipq 
Object (Referenced) 
15 ♦ Exception (Unchanged) 

• • Programming Exception 

• • • Kernel Exception 

• • • • Execution Kxcentlnn 

20 ExecutionExceptinn * 

abstract interface (KernelException) = {) ; 

Subclasflf*^ 

Argument Invalid; 

interface (ExecutionException) - (); 

25 An argument does not satisfy the argument's 

constraint. 

Aroumenf Missinq ■ 

interface (ExecutionException) - (); 
An argument is not on the stack. 
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At t ributeReadOnlv ; 

interface (ExecutionException) = () ; 

5 

An attribute is read-only, and thus cannot be set. 

10 ClassUna vai lable ■ 

5 interface (ExecutionException) « (); 



IS 



A class is in neither attribute "privateClasses" of 
the current process nor attribute "publicClasses" of the 
current place. 



20 Escalationlnvalid : 

10 interface (ExecutionException) - () ; 



25 
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A feature is escalated improperly. 
FeatureUnavailabl^. 

interface (ExecutionException) = (); 



An identifier does not denote an accessible feature 
15 of the responder. 

IntemalEyr^pptiop. 
interface (ExecutionException) « {); 

40 An Engine fails to fully implement the Instruction 

Set. 



20 PropertvUndefinedr 

interface (ExecutionException) a (); 



An identifier does not denote a property accessible 
so to the current method. 

Ref erenc eProtegtf^r; ^ ■ 

55 
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interface (ExecutionException) = () ; 

A reference to an object prevents the object's 
modification. 

Ref erenceVoid: 
5 interface (ExecutionException) = () ; 

A reference is void. 

Responde rMissinq; 

interface (ExecutionException) = () ; 

A feature is requested when the stack is cleared. 

10 Result Invalid. 

interface (ExecutionException) = () ; 

A result does not satisfy the result's constraint. 
ResultMisainq: 

interface (ExecutionException) = (); 
15 A result is not on the stack. 

VariableUndefined; 

interface (ExecutionException) « () ; 

An identifier does not denote a variable. 

4.30 Feature 
20 Object (Referenced) 
• Feat:m7^ 



50 Cl^aa 

Feature : 

55 
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10 



abstract interface « (...); 

This class is sealed. 

Construction 

initializer 
5 unprotected op ( 

isPublic: Boolean I Nil; 
^5 exceptions: Set [Identif ier! ] |Nil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "exceptions" and 
10 "isPublic") . If an argument is a nil, however, the 
corresponding attribute is cleared or made "false", 
respectively. 



20 
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Public Instance At^nribut^^ 

15 Set [Identifier!]; 

The identifiers denoting the classes of which the 
exceptions thrown by the feature the responder defines are 
members. The identifiers are interpreted according to the 
"vocabulary" attribute.of the interface that includes the 
20 responder. 

isPublie* 
Boolean; 

Whether the feature that the responder defines is 
public, i.e., not private. 

25 4.31 Hashed 
Hashed 
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Class 

Hashed: 

abstract interface 0 = (...); 

Public Instance Attribute^ 
5 hash: 

abstract readonly Integer; 

The responder's hash. 

4,32 Xdeptj^ier 
Object (Referenced) 
10 • Primitive (Executed & Unchanged) 
• • Identifier (Ordered) 

Class 

sealed interface (Primitive, Ordered) = () ; 
15 Adaptations 

One identifier is after another according to 
their texts. 

20 One identifier is before another according to their 

texts. 

Two identifiers are equal according to their texts. 
•Conversions 

25 S££lna 

A string that is valid as an identifier's text 
produces that identifier. 
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4.33 ImpleTnentation 
Ob j ec t ( Re f erenced ) 
• Implementation 



Class 

Implementatior^- 

sealed interface a (...); 



Construction 

initialize: 

unprotected op (superclasses: List [Identifier •] |Nil; 
10 vocabulary: Lexicon [Citation] |Nil; 

properties: List [Identif ier ! ] iNil.- 
instanceMethods, setMethods, classMethods, 
fromMethods, toMethods: Lexicon [Method] | Nil) ; 

Makes the responder's native attributes the 
15 like-named arguments (arguments "classMethods" , 
"fromMethods" , "instanceMethode" , "properties" , 
"setMethods", "superclasses", "toMethods", and 
"vocabulary") . If an argument is a nil but the 
corresponding attribute is not permitted to be a nil, 
20 however, the corresponding attribute is cleared. 



Public Instance Attribut^^ 
classMethodfl > 
Lexicon [Method] ; 



Methods- -for class operations, including operation 
25 "ofGet", other than operation "aSet" which is 

disallowed- -native to a class incorporating the responder. 
Each value is a method for performing the operation the 
associated key denotes . 

fromMethods: 
30 Lexicon (Method] ; 
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10 



Methods- -for converting from other classes- -native to 
a class incorporating the responder. Each value is a 
method for converting from the class the associated key 
denotes . 

5 Note: In an implementation of class "Dictionary", if 

the class identified is class "List", the 
conversion is that whose responder is class 
"Dictionary" and whose signature is "List: op 
^5 (list: protected List) Dictionary". 

10 j.n5tan?eMet^oqlg' 
Lexicon [Method] ; 



20 



25 



Methods--for instance operations, including operation 
"OfGet", other than operation "aSet" (see attribute 
"setMethods") --native to a class incorporating the 
15 responder. Each value is a method for performing the 
operation the associated key denotes. 

30 properties: 

List [Identifier!]; 

The identifiers of properties native to a class 
35 20 incorporating the responder. Their order has no 

significance in the interpretation of the disclosed 
instruction set. However, the order of the properties is 
significant in the Encoding Rules disclosed in Appendix B 
of this disclosure. 

25 setMethods: 

Lexicon [Method] ; 



40 



45 



Methods--for "ofSet" instance operations- -native to a 
class incorporating the responder. Each value is a method 
so for performing the operation the associated key denotes. 
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superclaaaeg; 

List [Identifier!] jNil; 

Either the identifiers of the implementation 
immediate superclasses of a class incorporating the 
5 responder, if they differ from the class' interface 

immediate superclasses, or a nil, otherwise. The classes' 
canonical order is that of their identifiers; the last 
class shall be a flavor. 

toMethods: 
10 Lexicon [Method] ; 

Methods--for converting to other classes- -native to a 
class incorporating the responder. Each value is a method 
for converting to the class the associated Jcey denotes, 
liffitfi: In an implementation of class "Dictionary", if 

1^ class identified is class "List", the 

conversion is that whose responder is a 
dictionary and whose signature is "List: op () 
List". 



vocabulary! 
35 20 Lexicon [Citation] | Nil; 

Either the user-defined classes to which the 
responder refers, if they are not those to which the 
40 class' interface refers, or a nil, otherwise. Each value 

is a citation to the class the associated key denotes. 
25 The attribute guides the interpretation of the responder' s 
"fromMethods", "superclasses", and "toMethods" attributes 
(and no others) . 

Adaptations 
isEmial 

50 
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Two implementations are equal according to their 
native attributes. 

4 . 34 Integer 
Obj ect (Referenced) 
5 • Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Inteq^ir 

Integer: 

10 sealed interface (Number) = (...); 

^ Public Instance O oerationg 

mQdulua ; 

op (divisor: Integer) Integer 
throws DivisionByZero; 
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15 Returns the arithmetic remainder of the responder, 

the dividend, and the integer (argument "divisor"), the 
divisor. The former's sign determines the result's. 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 

20 quotient! 

op (divisor: Integer) Integer 
throws DivisionByZero; 

Returns the arithmetic quotient of the responder, the 
dividend, and the integer (argument "divisor"), the 
25 divisor. 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 
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Adaptations 
aba 

The result is an integer. 

add 

5 The result is a real if the argument is a real, an 

integer if an integer. 

diving 

The result is a real if the argument is a real, an 
integer if the argument is an integer and the result would 
10 be exact, and a real, otherwise. 

multiply 

Same as described above for operation "add'*. 

25 negate 

The result is an integer. 



10 



IS 



20 



15 subtract 

Same as described above for operation "add" . 

ConvQrsipns 
lit 

The bits "zero- and "one" produce zero and one, 
20 respectively. 

A bit string that can be produced by converting some 
integer produces the integer. 

25 The booleans "false" and "true" produce zero and one, 

respectively. 

so Character 
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A Character produces the integer in [0, 65535] that 
is the character's Unicode code. 

Octet 

An octet produces the result of first converting the 
5 octet to an octet string, and then converting the octet 
string to an integer. 

oct^t;?^ripg 

An octet string that can be produced by converting 
some integer produces the integer. 

20 10 Real 

A real produces the integer that results from 
performing operation "truncate". 
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Spying 

A string that obeys the syntactic rules for the 
15 "Integer" token in Character Telescript produces the 
corresponding integer. 



4 .35 Interchangei ^ 
Unchanged 
35 • Interchange^ 



20 £iaaa 

Interchanai^d r 

abstract interface (Unchanged) » (..J; 



Public Instance Attr^h11^^« 
45 digest;, : 

25 abstract readonly protected Object |Nil; 



Either the digest of the reaponder, if the responder, 
i.e., this particular instance of the class, is 
interchangeable, or a nil, otherwise. 
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4.36 Int^rf^cpQ 

Ob j ect (Referenced) 

Class 
5 Interface; 

sealed interface = (...); 

CQnstryctiQn 

initialize; 

unprotected op (superclasses: List [Identifier!] |Nil; 
vocabulary: Lexicon [Citation] | Nil; 
instanceFeatures : Lexicon [Feature] |Nil; 
sealedlnstanceFeatures : Set [Identif ier > ] |Nil; 
classFeatures : Lexicon [Feature] |Nil; 
sealedClassFeatures: Set [Identifier!] |Nil; 
15 isAbstract: Boolean ( Nil ) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "classFeatures" , 
"instanceFeatures-, "isAbstract", "sealedClassFeatures", 
" sealedlnstanceFeatures " , " superclasses - , and 

20 "vocabulary"). If the corresponding argument is a nil, 
however, attribute "isAbstract" is made "false", attribute 
"superclasses- is made a list of the identifier of class 
"Object" alone, or the attribute is cleared if the 
attribute is other than attribrutes "isAbstract- and 

25 "superclasses". 

Public Instanrp Rttribi^i-i=>^ 
classFe atures: 
Lexicon [Feature) ; 

The class features native to a class incorporating 
30 the reaponder. Each value is the feature definition of 
the feature the associated key denotes. 
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Lexicon [Feature] ; 



The instance features native to a class incorporating 
the responder. Each value is the feature definition of 
5 the feature the associated key denotes. 



isAbstract : 
Booleoui; 

Whether a class incorporating the responder is 
abstract. 

10 sealedClassFeatures : 

Set [Identifier*] ; 

The identifiers of the class features that are either 
native to or inherited by a class incorporating the 
responder, and that are sealed by that class. 

30 15 sealedlnstanceFeatnr^c^ . 

Set [Identifier!]; 



The identifiers of the instance features that are 
either native to or inherited by a class incorporating the 
responder, and that are sealed by that class. 

20 superclasses: 

40 

List [Identifier!]; 

The identifiers of the interface immediate 
^ superclasses of a class incorporating the responder. The 

classes' canonical order is that of their identifiers; the 
25 last class shall be a flavor. 

50 v<?<??^fc>tilflry; 
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Lexicon [Citation] ; 

The uger-defined classes to which the responder 
refers. Each value is a citation to the class the 
associated key denotes. The attribute guides the 
5 interpretation of the responder' s "superclasses" 
attribute and no others. 

Adaptationg 
isSqy^J, 

Two interfaces are equal according to their native 
10 attributes. 



^ 4.37 Kernel Except^ior^ 

Ob j ect (Referenced) 
• Exception (Unchanged) 

25 • • Progranuning Exception 

15 • • • Kernel F-« ;ceptiQn 
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Class 

KernelEx ception; 

abstract interface (ProgrammingException) « () ; 

20 ClassAbatra^t;; . 

interface (KernelException) (); 

An object's proposed class is abstract. 



ConversionUnavai 1 aY^] ^ ; 
^ interface (KernelException) - () ; 

25 An object's proposed conversion is undefined. 



CopvUnavai,1^h1^. 

interface (KernelException) = () ; 
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An object's property cannot be copied. 



10 



IS 



LoopMissina; 

interface (KernelException) « () ; 

A loop is broken or continued where no loop exists. 
MaricMissino: 

interface (KernelException) - () ; 



A stack's items do not include a mark. 



20 



Obi ectOninitialized r 

interface (KernelException) « (); 



25 



10 An object attempts to use one of its features before 

escalating operation "initialize". 



30 
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15 



interface (KernelException) » (}; 

An object's proposed passage is invalid. 

SelectorPuDlicatedi 

interface (KernelException) « {); 



40 
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so 



20 



Two selectors are equal. 

4.38 hS^jcm 

Object (Referenced) 
Collection 

• Set 

• • Dictionary 

• • • Constrained Dictionary (Constrained) 

• • • • Lexicon 
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Claaa 

interface [valueClass: Class] 

(ConstrainedDictionary [Identifier, valueClass]) 
5 . (...); 

Parameterized by the class (argument "valueClass") of 
which the value of each item of each member of the subject 
class is itself a member. 

Construction 
10 initialize: 

unprotected op (keysAndValues: Object 

/* key: Identifier!; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 

15 Makes the responder's items associations between the 

key- value pairs (argument "keysAndValues"). 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated"), a proposed key is invalid as such 
("Keylnvalid") , or the number of objects is odd 

20 ("ObjectsUnpaired") . 



Adapt^t;L9ng 

constraint 

The attribute is sealed. The attributes -ofClass", 
^ "classld", "islnstance-, " isOptional" , and "passage" 

25 attributes are class "Identifier", the identifier of class 
"Identifier", "true", "false", and "byCopy", respectively. 

48 Conversiopj^ 

A dictionary whose keys satisfy the constraints of a 
30 lexicon produces the lexicon, 

50 
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4.39 List 
g Object (Referenced) 

• Collection 

• • Liat (Ordered) 

10 5 Class 

interface [itemClass: Class] 

(Collection [itemClass] , Ordered) = (...); 

15 

Parameterized by the class (argument "itemClass") of 
10 which each item of each member of the subject class is 
20 itself a member. 

initialize: 

unprotected op (items: itemClass . /. ) ; 

15 Makes the responder's items the objects (argument 

^ "items")/ whose positions increase from left to right. 

Public Instance Qperationg 
add: 

?5 unprotected op (position: Integer; item: itemClass) 

20 throws Itemlnvalid, Posit ionlnva lid; 

Includes the object (argument "item") in the 
responder as a new item, one whose position equals the 
integer (argument "position"), increasing by one the 
position of each item whose position is equal to or after 
15 25 that of the included item. 

An exception is thrown if the proposed item is 
invalid as such ("Itemlnvalid") or the proposed position 
is invalid as such ("Positionlnvalid") . 

0 

drop: 
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unprotected op (position: Integer) itemClass 
throws Positxonlnvalid; 

Excludes from the responder and returns the item 
whose position equals the integer (argument "position"), 
5 decreasing by one the position of each item whose position 
is after that of the excluded item. 

An exception is thrown if the asserted position is 
invalid as such ("Positionlnvalid") . 

findl 

10 op- (initialPosition: Integer; item: protected 

itemClass) 

Integer I Nil 
throws Ppsitionlnvalid; 

Leaves in the responder and returns the position of 
15 the item that equals the object ("item") and whose 

position is not before the integer ("initialPosition"). 
If the responder has several such items, the one whose 
position is least is selected. If it has none, a nil is 
returned. 

An exception is thrown if the asserted position is 
invalid as such (" Posit ionlnvalid" ) , 



20 



op (position: Integer) itemClass 
throws Positionlnvalid; 



25 Leaves in the responder and returns the item whose 

position equals the integer (argument "position") . 

An exception is thrown if the asserted position is 
invalid as such ("Positionlnvalid"). 



rePoaitinn> 
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unprotected op (currentPosition, newPosition: 
Integer) 

throws Positionlnvalid; 

Changes to the second integer (argument 
5 "newPosition") the position of the responder's item whose 
position equals the first integer (argument 
"currentPosition"), The operation achieves this as if by 
means of operations "drop" and "add", except that the 
second integer is interpreted before, rather than after, 
10 operation "drop" is requested. 

An exception is thrown if an asserted position is 
20 invalid as such {"Positionlnvalid"). 

set : 

unprotected op (position: Integer; item: itemClass) 
15 throws Itemlnvalid, Positionlnvalid; 



10 
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Excludes from the responder the item, if there is 
one, i.e., if the new item is not being appended, whose 
position equals the integer (argument "position"), and 
includes the object (argument "item") as a new item at the 
20 same position. 
35 An exception is thrown if the proposed item is 

invalid as such ("Itemlnvalid") or the proposed position 
is invalid as such ("Positionlnvalid"). 



40 



45 



50 



transpose; 

25 unprotected op (positionl, position2 : Integer) 

throws Positionlnvalid; 

Transposes the responder' s items that occupy the two 
positions (arguments "position!" and "positions"). 

An exception is thrown if an asserted position is 
30 invalid as such ("Positionlnvalid"). 
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exclude 

The operation decreases by one the position of each 
object whose position is after that of the excluded item. 

5 include 

The position of the newly included item is the list's 
new length. 

isEcrual 

Two lists are equal only if their like-positioned 
10 items are equal. 

stream 

The stream produces the list's items in order of 
increasing position. 

15 PyPCQduyg 

A procedure produces a list of the same length, each 
of whose items is a copy of the item at the same position 
in the procedure. 

4.40 Mark 
20 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • MaEk 

Class 

Mark: 

25 sealed interface (Primitive) « () ; 

Adflpta^^;j,Ong 
isEoual 

Any two marks are equal. 
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4.41 Means 
Object (Referenced) 

Class 
5 Means : 

abstract interface ( ) ; 

4.42 Heating, Exg^ption 
Object (Referenced) 

• Exception (Unchanged) 
10 • • Meeting Except log 

Class 

MeetlngException: 

abstract interface (Exception) « (); 
Subclasses 

15 Mggtjvnqpgniedj. 

interface (MeetlngException) o (}; 

The petitionee denies the petitioner the meeting. 

MeetinoDuplicatedr 

interface (MeetlngException) « (); 

20 The petitioner and petitionee are the same or meeting 

already. 

Meetinqinvalid. 

interface (MeetlngException) =• (); 

A contact does not represent a meeting, 

!5 PetitionExpired: 

interface (MeetlngException) (); 
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The petitionee cannot be met in the time allowed. 



4,43 Meeting PI a^A 
Object (Referenced) 

• Process (Named) 

5 • • Place (Unmoved) 

• • • Meeting Plar^o 



Class 

MeetingPlac^; 

abstract interface (Place) ={...); 



10 Public Tnst^nce On^T-^ri-nff 
meet: 



unprotected op (petition: copied Petition) Contact 
throws MeetingException, ProcessNot Current , 
25 Statelmproper; 



15 



20 



Begins a meeting between the agent requesting the 
operation and the one the petition (argument "petition") 
Identifies, returning a contact whose "subject" attribute 
is the latter. The latter agent must also occupy the 
responder. 

An exception is thrown if the meeting failed 
(-MeetingException-), the responder is not the current 
place ("ProcessNotCurrent"), or the requester's state 
precludes -meet" ("Statelmproper"). 



part: 

25 unprotected op (contact: Contact) 

45 throws Meetinglnvalid, ProcessNotCurrent , 

Statelmproper; 



30 



Ends the meeting between the agent requesting the 
operation and the subject of the contact (argument 
"contact"), making the contact's "subject" attribute a 
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nil, if the attribute is not a nil already. The subject 
must also occupy the responder. 

An exception is thrown if the contact is not a 
meeting's ( "Meetinglnvalid" ) , the responder is not the 
5 current place ( "ProcessNot Current ") , or the requester's 
state precludes operation "part" ( "State Improper " ) . 

part All: 

unprotected op () 

throws ProcessNotCurrent , Statelmproper; 

10 Ends all meetings that involve the requesting agent, 

and then isolates the agent . 

An exception is thrown if the responder is not the 
current place (" ProcessNot Current " ) or the requester's 
state precludes operation "partAll" ("Statelmproper") . 

15 4.44 Mellisd 

Object (Referenced) 
• Method 

Class 

Method: 

20 sealed interface = (...); 

Cons truer, inn 

i,^d,t;4al3,zg; 

unprotected op (procedure: Procedure | Nil ; 
variables: List tidentif ier ! ] | Nil) ; 

25 Makes the responder' s native attributes the 

like-named arguments (arguments "procedure" and 
"variables"). If an argument is a nil, however, the 
corresponding attribute is cleared. 

Public Instar^g^ Attrlhi^^A? 
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Drocedurf> 
Procedure / 

The responder's procedure. 

variables : 
5 List [Identifier!]; 

The identifiers of the responder's variables, their 
order having no significance with respect to the 
interpretation of the disclosed instruction set. However, 
the order of the variables is significant in the Encoding 
10 Rules described in Appendix B of this disclosure. 

Adaptationfl 
igSOWfll 

Two methods are equal according to their native 
attributes, 

30 15 ^--^S Miscellaneous 5xf7f>p^^on 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

^ • • • Miscellaneoug Eyr^phS^n 

20 Class 

MigcellaneouflExceptinT^ ; 

abstract interface (ProgrammingException) = {); 



10 
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40 



Subclaggfifl 
45 Patternlnvali'rf. 

interface (MiscellaneousException) = {) ; 



50 
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A pattern's proposed text is syntactically in error, 
Seedlnvalid- 
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interface (MiscellaneousException) ^ () ; 

A random stream's proposed seed is not in the 
required range. 

4.46 MQcjAfier 
10 5 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Modifier 
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Class 

10 sealed interface (Primitive) = (); 

Adaptatlong 

Two modifiers are equal iff their values are the 

same. 



15 4.47 Named 
30 Named 



Class 

Named : 

abstract interface () « (...); 

20 gop9tru<?tipn 

initialize 



Makes the responder's "name" attribute a newly 
^ assigned telename, a peer of the current process'. 

Public Instance A1^^r^ Hn^ocy 

25 name; 



sealed readonly protected Telename; 
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The responder's assigned telename, 
4.48 Hii 

Ob j ect (Referenced) 

• Primitive (Executed & Unchanged) 
5 • • Nil 

Class 

Niii. 

sealed interface (Primitive) = () ; 
Adaptations 

Any two nils are equal. 

4.49 Numlper - 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
15 • • Number (Ordered) 

Class 

Number: 

abstract interface (Primitive, Ordered) = ( . 
This class is sealed. 
20 Public Instang^ Opera^^9 nfl 
abstract op () Number; 

Returns the absolute value of the responder. 
adil 

25 abstract op (number: Number) Number ; 
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Returns the arithmetic sum of the number ("number") 
and the responder, 

ceiling: 

abstract op () Integer; 

5 Returns the smallest integer that is arithmetically 

greater than or equal to the responder. 

divide: 

abstract op (divisor: Number) Number 
throws DivisionByZefo; 

20 

10 Returns the arithmetic quotient of the responder, the 

dividend, and the number (argument "divisor"), the 
divisor. 

25 An exception is thrown if the divisor is zero 

("DivisionByZero") . 

15 floor: 

abstract op () integer; 

Returns the largest integer that is arithmetically 
less than or equal to the responder. 



30 



35 



multiply: 

20 abstract op (number: Number) Number; 

40 

Returns the arithmetic product of the number 
("number") and the responder, 

negate : 

abstract op {) Number; 
50 Returns the arithmetic negative of the responder. 
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abstract op () Integer; 

Returns the single integer that is, or one of the two 
integers that are, arithmetically nearest to the 
5 responder. 

subtract : 

abstract op (subtrahend: Number) Number; 



Returns the arithmetic difference between the 
responder, the minuend, and the number (argument 
20 10 -subtrahend"), the subtrahend. 



truncate : 

abstract op () Integer; 



Returns the integer formed by discarding the 
responder' s fractional part so as to arithmetically 
15 truncate the responder toward zero. 



isAfter 

35 One number is after another iff the first is greater 

than the second. 



20 isBefore 

One number is before another iff the first is less 
than the second. 

isEoual 

Two numbers are equal iff they are equal 
25 mathematically. 

4.50 Object 

Object (Referenced) 
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Class 

abstract interface (Referenced) = {...); 

Construction 
5 ^njTtiaJ,izg! 

unprotected op {} ; 

Initializes the responder, a potential object, and 
makes the responder an object* 

finalize; 
10 unprotected op () ; 

Requested as the responder is destroyed by operation 
"discard". A method for thiis operation finalizes the 
object with respect to the method's class. 

Public Instance Attribut^^a 
15 class : 

sealed readonly Class ; 

Either the class of which the responder is an 
instance, if the responder is not class "Class", or class 
"Class", if the responder is indeed class "Class". 

20 size: 

sealed readonly Integer; 

The responder's size in octets, i.e., the approximate 
amount of storage that destroying the responder would 
reclaim. 

25 Public Instance O perationa 
copy : 

sealed op () copied Object 
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throws CopyUnavailable; 

Returns either the responder, if the operation is 
requested using the only reference to the responder, or a 
copy of the responder, otherwise. 
5 An exception is thrown if a copy if unavailable 

("CopyUnavailable") . 

isEoual : 

op (object: protected Object) Boolean; 

Returns an indication of whether the object (argument 
10 "object") equals the responder. 

A method shall escalate this operation if either the 
responder or the object is not a member of the class to 
which the method is native. The method native to class 
"Object" deems the two equal iff they are the same object. 

15 select; 

sealed op (associations: Object ... 

/* protected Object; Executed */) 
throws Exception, SelectorDuplicated; 

From the pairs of objects and executed objects 
20 (arguments -associations"), selects and performs at most 
one executed object. The one selected gets access to the 
requester's frame and properties, not the responder- s. 

If an object equals the responder, the executed 
object paired with that object is selected, otherwise, if 
25 any object is a nil, the executed object paired with that 
object is selected. Otherwise, no executed object is 
selected. 

An exception is thrown if the selected executed 
object does so (-Exception-) or two objects paired with 
30 executed objects are equal ("SelectorDuplicated"). 
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Internal Instance Opera tiinnfl 
aetAttribute: 

sealed op (identifier: Identifier) Object 

throws ClassUnavailable, FeatureUnavailable; 

5 Returns the responder's attribute denoted by the 

identifier (argument "identifier"). The attribute follows 
the passage prescribed for the attribute. 

An exception is thrown if the class the identifier's 
qualifier denotes is absent ("ClassUnavailable") or the 
10 identifier denotes no attribute of the responder that is 
accessible to the requester ("FeatureUnavailable'*). 

qgtClflgg; 

sealed private op (identifier: Identifier!) Class 
throws ClassUnavailable; 

15 Returns the class the identifier (argument 

"identifier") denotes to the current method. 

An exception is thrown if the class is absent 
("ClassCTnavailable") . 



qgtpprppQrt^;. 

35 20 sealed private op (identifier: Identifier!) Object 

throws PropertyUndefined; 



Returns the responder's property that is both denoted 
by the identifier (argument "identifier") and native to 
the class to which the current method is native. The 
25 returned reference is protected iff the responder is 
protected. 

An exception is thrown if the identifier is invalid 
("Propertyandefined") . 



50 aetVariahl^T 

sealed private op (identifier: Identifier!) Object 
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throws VariableUndefined; 

Returns the current method's variable the identifier 
(argument "identifier") denotes. 

An exception is thrown if the identifier is invalid 
5 ( "VariableUndefined" ) . 

setAttributP; 

sealed unprotected op (identifier: Identifier; 

at tribute: Object) 
throws Argument Invalid, AttributeReadOnly, 
iO ClassUnavailable, FeatureUnavailable; 

Makes the object (argument "attribute") the 
responder's attribute denoted by the identifier (argument 
"identifier"). The operation first discards the attribute 
if it exists. The object follows the passage prescribed 

15 for the attribute. 

An exception is thrown if the object violates the 
attribute's constraint ( "Argument Invalid" ) , the attribute 
is read-only ("AttributeReadOnly" ) , the class the 
identifier's qualifier denotes is absent 

20 ("ClassUnavailable") , or the identifier denotes no 
attribute of the responder that is accessible to the 
requester ("FeatureUnavailable"). 



setPropertvi 

40 sealed private unprotected op (identifier: 

25 Identifier!; 

property: Object) 
throws PropertyUnde fined; 

45 

Makes the object (argument "property") the 
responder' s property that is both denoted by the 
30 identifier (argument "identifier") and native to the class 



55 



256 



BNSDOCID: <EP_0634719A2J_> 



EP0634 719 A2 



10 



15 



20 



25 



to which the current method is native. The operation 
first discards the property if the property exists. 

An exception is thrown if the identifier is invalid 
( " Proper tyUndefined" ) . 

5 setVariable : 

sealed private unprotected op (identifier: 
Identifier In- 
variable: Object) 
throws Var iableUnde fined; 

XO Makes the object (argument "variable") the current 

method's variable the identifier (argument "identifier") 
denotes. The operation first discards the variable if the 
variable exists. 

An exception is thrown if the identifier is invalid 

15 ("VariableUndefined") . 



4.51 Octet 
30 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Octet (Ordered) 

^ 20 Class 

Octet : 

sealed interface (Primitive, Ordered) = () ; 

40 

i?A^^Qff 

25 One octet is after another iff two of their 

45 like-numbered bits are unequal and the first octet's 

highest -numbered such bit is after the second's. 
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isBefore 

5 One octet is before another iff two of their 

like-numbered bits are unequal and the first octet's 
highest -numbered such bit is before the second's. 

10 5 isEoual 

Two octets are equal iff neither is before the other. 



IS 
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CgnygypiQPa 

A bit produces an octet whose Bit 0 equals the bit 
10 and whose Bits .1-7 are zero. 



Character 

A character whose Unicode code is an integer in [0, 
127) produces the octet' that converting that integer 
25 produces. 

15 Int^qgg 

^ An integer in the range of 1-128, 127] produces the 

octet that forms the integer's twos' complement 
representation. Bit 7 represents -128, while Bit "n" 
represents 2\ for each "n" in the range of [o, 6]. 

20 OctetStrin^ 

An octet string with one item produces an octet equal 
to that item. 

4.52 Octet fii-r-i^^ 
Object (Referenced) 
25 • Collection 

• • List (Ordered) 

• • • Constrained List (Constrained) 

• • • • Octet fi^r•^pq (Executed) 

Class 
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Qct^tStyj^nq: 

5 sealed interface { Const rainedList [Octet] , Executed) 

«(...); 

Const; rue? tiQn 
10 5 initialize: 

unprotected op (segments: Object ... 

/* Octet [protected OctetStringl */) ; 



15 



20 



30 



35 



40 



Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
10 increase from left to right. 



cypRStyaifit 

The attribute is sealed. The attribute's "ofClass", 
"classid", "islnstance", "isOptional" , and "passage" 
15 attributes are class "Octet", the identifier of class 
"Octet", "true", "false", and "byCopy" , respectively. 



One octet string is after another as if all -zero 
octets were first prepended to the shorter octet string to 
20 make the shorter octet string equal in length to the 
longer octet string. 

jsBfi^pre 

One octet string is before another as if all- zero 
octets were first prepended to the shorter octet string to 
25 make the shorter octet string equal in length to the 
^ longer octet string. 

Conversions 

50 
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A bit produces the octet string that results from 
first converting the bit to an octet, and then converting 
the octet to an octet string. 

BitStrina 

5 A bit string whose length is "n" produces an octet 

string whose length is "i" . «n" is in the range [8i, 
8i+7] . Bit "j« of the octet at position "k" of the octet 
string either equals the bit at position (8k -j) of the 
bit string, if (8k -j) sn, or is zero, otherwise. 



10 gh^ract^y 
20 A character that can be produced by converting some 

octet string whose length is two produces that octet 
string. 



Integer 

15 An integer in the range [-2«"S , for an integer 

"n" and none smaller, produces an octet string whose 
length is "n" . A twos' complement representation is used, 
wherein Bit 7 of the octet whose position is one 
represents •2«»'^ while every other Bit "j" of the octet at 

20 position "i" in the octet string represents 2»^'^*j. 

Octet 

An octet produces an octet string whose only item 
equals that octet. 

2 5 A string produces a "characters" token for encoding 

the string in a binary telescript. 



4.53 Operation 
Object (Referenced) 
50 • Feature 

30 • • Operation 
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Class 

Operation: 

5 

sealed interface (Feature) -{...); 

10 5 initialize : 

unprotected op (arguments; List [Constraint] | Nil ; 
result: Constraint | Nil ; 
isPublic: Boolean I Nil; 
exceptions; Set [Identifier!] |Nil) ; 

10 MaJces tlie responder's attributes the like-named 

arguments (arguments "arguments", "exceptions", 
"isPxiblic", and "result"). If argument "exceptions" or 
argument "isPublic" is a nil, liowever, the corresponding 
attribute is cleared or made "false", respectively. 

25 

15 Public Instance Atitrit;»ii-^ei 
List [Constraint] |Nil; 

Either the constraints upon the zero or more 
arguments of the operation that the responder defines, if 
20 they do not vary in number, or a nil, otherwise, in which 
case each is passed by reference and can be any object but 
a mar)c. The list's first item constrains the argument on 
top of the stack. 

result: 
25 Constraint [Nil; 

45 Either the constraint upon the result of the 

operation that the responder defines, if the operation has 
a result, or a nil, otherwise. 



30 



35 



40 



50 



Adaptations 
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isEqual 

Two operation definitions are equal according to 
their attributes native to feature and operation 
definitions . 

5 4.54 Qrdey^4 
Ordered 

Claa^ 

abstract interface ( ) ^ (...); 

10 Public Instance Q peratipn g 
isAfter; 

abstract op (object: protected Ordered) Boolean; 



Returns an indication of whether the responder is 
after the object (argument "object"). 
15 A method shall escalate this operation if either the 

responder or the object is not a member of the class to 
30 which the method is native. 

isBefore; 

abstract op (object: protected Ordered) Boolean; 



20 Returns an indication of whether the responder is 

before the object (argument "object"), 
^ A method shall escalate this operation if either the 

responder or the object is not a member of the. class to 
which the method is native. 

46 25 max; 

op (object: Ordered) Ordered; 
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Returns either the responder, if the responder is 
after the object (argument "object"), or the object, 
otherwise. 



op (object: Ordered) Ordered; 



Returns either the responder, if the responder is 
before the object (argument "object"), or the object, 
otherwise . 



4.55 Package 
20 10 Object (Referenced) 

• Collection 

• • Set (Verified) 

• • . • Constrained Set (Constrained) 

• • • • Package (Cited & Interchanged) 



15 Class 

Package t 

interface (ConstrainedSet [Class] , Cited, 
Interchanged) 

= (,..); 

20 CgngtyyC^t^on 

initialize: 

unprotected op (title: Identifier!; 
majorEdition, minor Edit ion: 
-Integer ; items : Class . . . ) 
25 throws ItemDuplicated, ProcessNotPeer; 

Makes the responder' s items the classes (argument 
"items") and the responder' s "citation" attribute a 
citation whose "author" attribute is the current process' 
assigned telename and whose other attributes are the 
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like-named arguments (arguments "majorEdition" , 
"minorEdition" , and "title"). 

An exception is thrown if two classes are equal 
("ItemDuplicated") or the current process is not a class' 
5 peer ("ProcessNotPeer") . 

Adaptat:iftnfi 

constrain^; 

The attribute is sealed. The attribute's "ofClass", 
"classid", "islnstance", "isOptional" , and "passage" 
10 attributes are class "Class", the identifier of class 
"Class", "true", "false", and "byCopy", respectively. 

4.56 £att£m. 
Object (Referenced) 
• Pattern (Ordered) 

15 giagg, 

Pfltt^yj;^; 

interface (Object, Ordered) - {.,.); 

Conatrugtirtn 

initiallzi>; 

20 unprotected op (text: copied String!) 

throws Patternlnvalid; 

Makes the responder's text the string (argument 
"text") . 

An exception is thrown if the proposed text is 
25 invalid ("Patternlnvalid"). 

Public In^^^^^r^o np^^^^^^^^ 

op (string: protected String!; position: Integer |Nil) 
List [Integer] |Nil 
30 throws Positionlnvalid; 
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Searches the string (argument "string") for the first 
and longest possible substring that matches the responder. 
The search begins either at the prescribed position 
(argument -position") , if an integer is supplied, or at 
5 position one, otherwise. 

The operation returns either a nil, if the operation 
finds no match, or a list of two integers, otherwise, in 
the latter case, the first integer is the position in the 
string of the first character in the match. The second 
10 integer is one greater than the position in the string of 
the last character in the match. 

An exception is thrown if the proposed position is 
invalid as such, more specifically, less than or equal to 
zero ("Positlonlnvalid") . 
15 Nsts: The two integers in the list are suitable as the 
arguments of operation "svibstring" . 

substitute; 

op ( repetitions: Integer; 

string: unprotected String!; 
replacement: protected String!) 
Integer; 



20 



Searches the first string (argument "string"), 
beginning at position one, for the longest possible 
substrings that match the responder, and modifies the 
25 string by replacing each match with a copy of the second 
string (argument "replacement") . 

The operation finds either all matches, if the 
integer (argument "repetitions") is zero, or at most that 
many, otherwise. Successive matches are non-overlapping. 
30 If one match is of zero length, the search for the next 
begins at the following position. The operation returns 
the number of matches actually found. 

The replacement string can be tailored for each 
individual replacement. Wherever an ampersand ("&") 
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appears in the replacement string without being 
immediately preceded by a reverse slash ("\"), a copy of 
the substring to be replaced is itself substituted for the 
ampersand, and the modified replacement string then is 
5 substituted for the substring. 

Ac^^pt;atj.onff 
isEoual 

Two patterns are equal according to their texts. 

CQHY^rgiong 
10 String 

A string that is valid as the text of a pattern 
produces that pattern. 



4.57 Permit 
25 Object (Referenced) 

15 • Permit (Ordered) 



Permit : 

interface (Object, Ordered) - (...); 
Construction 
20 initialig^ft; 

unprotected op (age, charges, extent: Integer | Nil); 

Makes the responder's attributes the like-named 
arguments (arguments "age", "charges", and "extent"). 
Makes every other native attribute of the responder either 
25 "true", if the attribute is a boolean, or a nil, 
otherwise. 



Public InBtannf^ f^t tributffc i 
age : 

^ Integer I Nil; 
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Either the maximum permitted age, measured in 
^ seconds, of the responder's subject, if a maximum is 

imposed, or a nil, otherwise. 

authenticity. 
10 5 Integer I Nil; 

Either the maximum permitted authenticity of the 
responder's subject, if a maximum is imposed, or a nil, 
otherwise. 



15 
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Charges : 
10 Integer I Nil; 



Either the maximum permitted charges, measured in 
teleclicks, of the responder's subject, if a maximum is 
imposed, or a nil, otherwise. 



15 Integer! Nil; 

Either the maximum permitted size measured in octets 
of the responder's subject, if a maximum is imposed, or a 
nil, otherwise, 

priority. 
20 Integer I Nil; 

Either the maximum permitted priority of the 
responder's subject, if a maximum is imposed, or a nil, 
^ otherwise, 

canChara<> , 
25 Boolean; 

50 
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Whether the responder's subject is permitted to 
request operation "charge". 



canCreaf^ff ^ 
Boolean; 



5 



Whether the responder's subject is permitted to 
request operation « new" of a subclass of class "Process" 

c^^^pegyj. 
Boolean; 

Whether the responder's subject is permitted to set 
10 the -nativePerndt" attribute of a peer process so as to 
decrease the peer process' capabilities. 

Whether, coincidentally, the responder's subject if 
otherwise entitled to do so, is permitted to so set a' 
process' -regionalPermit- or " local Permit- attribute . 

IS canGo! 

Boolean; 

Whether the responder's subject is permitted to 
request operation "go". 

canGran^ ; 
20 Boolean; 

Whether the responder's subject is permitted to set 
the -nativePermit" attribute of a peer process so as to 
increase the peer process' capabilities. 

Whether, coincidentally. the responder's subject, if 
25 otherwise entitled to do so, is permitted to so set a 
process- "regionalPermit" or "localPermit" attribute. 

canReB^ay^. 
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Boolean; 

Whether the responder's subject is peirmitted to be 
restarted. 

canSend : 
5 Boolean; 

IS Whether the responder's subject is permitted to 

request operation "send". 

Public Instance O perations 
10 op (permit; Permit) Permit; 



25 



30 



35 



Returns the intersection of the argument (argument 
'Vpermit") and the responder. 

Adapt^t;i,9ng 
isAfter 

15 One permit is after another iff they are not equal, 

no native attribute of the first is before that of the 
second, and at least one native attribute of the first is 
after that of the second. 



isBefort^ 

20 One permit is before another iff they are not equal, 

^ no native attribute of the first is after that of the 

second, and at least one native attribute of the first is 
before that of the second . 

46 isEcmal 

25 Two permits are equal according to their native 

attributes. 

« 4.58 Petition 
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Ob j ect (Referenced) 
5 • Petition 

Class 

*o 5 interface =(...); 

Construct i^ri 

unprotected op (agentName: Telename |Nil; 
agentClass: Citation I Nil ; 
10 maximumWait : Integer | Nil ) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "agentClass", "agentName", 
and "maximumWait") . 

Public Instance Attrihg^ ^g 
15 aq^ntCl^gff ; 

CitationjNil; 

Either a citation to the clasa, a subclass of class 
"Agent", of which the petitionee of the meeting the 
responder defines is a member, if such a constraint is 
20 imposed, or a nil, otherwise. 



15 
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agentName r 
40 Telename I Nil; 



45 



so 



Either a telename of the petitionee of the meeting 
the responder defines, if such a constraint is imposed, or 
25 a nil, otherwise. 



maximumW;^i,t ^ 
Integer I Nil; 
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Either the maximum permitted difference in seconds 
between the time at which the meeting the responder 
defines shall be arranged and the time at which the 
meeting is requested, if such a constraint is imposed, or 
5 a nil, otherwise. The integer, if supplied, is 
non-negative . 



A<j^fftc^t;ionq 
^5 isEoual 

Two petitions are equal according to their native 
10 attributes. .. 



4.59 Petitioned 

Petitioned 

Petitioned; 
15 abstract interface {) = (...); 

30 System Instance Qperatlong 

meeting; 

unprotected op (contact: Contact; 
petition: protected Petition) 
35 20 throws MeetingDenied; 

Successfully performed before the subject of the 
contact {argument "contact") meets the responder using the 
petition (argument "petition"). The contact's subject 
attribute is a nil while the operation is being performed, 
25 and is made the "subject" iff the operation succeeds. 

An exception is thrown if the meeting is denied 
("MeetingDenied"). The method for this operation native 
to the class throws an exception. 

SQ parting: 

30 unprotected op (contact: Contact); 
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Requested after the subject of the contact (argument 
^ "contact") has met with the responder. Before the 

operation is requested, the Engine makes the contact's 
"subject" attribute a nil. The method native to class 
5 "Petitioned" has no effect. 

10 

4,60 n^c^ 

Object (Referenced) 

• Process (Named) 

• • Place (Unmoved) 

10 C;agg 

abstract interface (Process, Unmoved) = (,,J; 
25 initialize 



Makes the responder' a "address" attribute a newly 
assigned telename, which is a peer of the current 
process', and clears the responder' s "publicClasses" 
attribute. 

Public Instance A ttrlbutfi fl 
address: 

sealed readonly protected Teleaddress; 
The responder' s assigned teleaddress, 
PUblicClasaeflr 

sealed readonly Set {Cited] ; 

The set of classes, packages, or both that the 
responder hereby makes accessible to its occupants. The 
attribute is either an unprotected reference, if the 
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requester is the place, or a protected reference, 
otherwise . 



Public Instance Operations 
terminate :. 
5 sealed unprotected op 

(occupant: protected Telename) Boolean 
throws ProcessNot Current, ProcessNotPeer, 
State Improper ; 

Terminates any occupant of the responder having the 
10 assigned telename (argument "occupant") and returns an 
indication of whether there was such a process. The 
process is terminated by forcibly exhausting the process' 
native permit. 

An exception is thrown if the responder is not the 
15 current place ( "ProcessNot Current ») , the current process 
is not the occupant's peer ("ProcessNotPeer") , or the 
requester's state precludes operation "terminate" 
("Statelmproper") , 

System Instance Qperatior^ ft 
20 entering; 

unprotected op (contact: Contacts- 
permit: protected Permit; 
ticket: protected Ticket | Nil) 
throws OccupancyDenied; 

25 Successfully performed before the subject of the 

contact (argument "contact") occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested, but is made the subject iff the operation 
succeeds . 

30 The subject is either an agent arriving with the 

ticket (argument "ticket"), if one is supplied, or a 
process being created in the responder, if a nil is 



273 



EP0 634 719 A2 



supplied. The permit (argument "permit") is the subject's 
proposed initial local permit. 

After this operation succeeds, iff the responder is a 
contacted object, the Engine includes the contact in the 
5 responder' s "contacted" attribute. 

An exception is thrown if the contact's subject is 
denied occupancy < "OccupancyDenied" ) . The method for this 
operation native to the class throws an exception. 
Nats-' If a ticket is supplied, the permit equals and, 

10 therefore, duplicates the ticket's 

"destinationPerrait" attribute. 

exiting: 

unprotected op (contact: Contact; 
permit: protected Permit; 
15 ticket: protected Ticket I Nil) ; 

Requested once the subject of the contact (argument 
"contact") no longer occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested. The method for this operation native to the 
20 class has no effect. 

The subject is either an agent leaving the responder 
with the ticket (argument "ticket"), if one is supplied, 
or a process being destroyed within the responder, if a 
nil is supplied. The permit (argument "permit") is the 
25 subject's current local permit. 

After this operation. is performed, iff the responder 
is a contacted object, the Engine excludes the contact 
from the responder 's "contacted" attribute. 

4,61 Primitive 
30 Object (Referenced) 

• Primitive (Executed & Unchanged) 

Class 
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Primitive^ 

abstract interface {Object, Executed, Unchanged) 
(...); 



This class is sealed. 



5 Constructing 

iuAtialize; 

unprotected op (> 

throws FeatureUnavailable; 



Throws an exception ("FeatureUnavailable"). 

10 4.62 Primitiv e Except!lQr^ 
Object (Referenced) 

• Exception (Unchanged) 

• • Prograimning Exception 

• • • Primiti ve Except! :;Qr^ 

15 Class 

PrimitiveExceptiftnr 

abstract interface (ProgrammingException) - () ; 

Subclasses 

DiviaionBvZe^^; 
20 interface (PrimitiveException) = (); 

A divisor is zero. 

4.63 Procedure 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
25 • • Procedure 
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sealed interface (Primitive) «(,..)/ 

Adaptatiqnj^ 
is Equal 

Two procedures are equal iff they are equal in length 
5 and their like -positioned items are equal. 



Conversions 
15 List 

A list whose items are executed objects produces a 
procedure of the same length, each of whose items is a 
10 copy of that in the same position. 



An octet string that is a binary telescript produces 
a procedure whose items are the objects the binary 
telescript encodes. 

15 String 

A string that is a character telescript produces a 
procedure whose items are the objects the character 
telescript encodes. 

4,64 Process 
20 Object (Referenced) 
• Process (Named) 

Cla^g 

Process t 

abstract interface (Object, Named, Uncopied) =(...); 
25 This class is sealed. 



so initialize; 

op ( nativePermit : copied Permit; 
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privateClasses: Set [Cited] | Nil) 
throws PermitViolated; 

Makes the responder's "name" attribute a newly- 
assigned telename, a peer of the current process'; the 
5 responder's attribute the like-named argument (argument 
"nativePermit") ; the responder's "privateClasses" 
attribute either the like-named argument (argument 
"privateClasses-), if the argument is not a nil, or the 
like -identified attribute of the current process, 
10 otherwise; and the responder's contacts attribute a 
cleared set. 

An exception is thrown if the current process' 
effective permit forbids operation "new", that permit is 
otherwise inadequate, or operation "entering" fails 
15 ("PermitViolated"). 

Note: The method for this operation native to a 

subclass of class "Process" sees the creating 
process, not the created one, as the current 
process . 



20 Public Instance At-M-j^i^t-of^ 
braod: 

sealed readonly protected Object 
throws ProcessNotPeer; 

The responder's brand. 
25 An exception is thrown if the current process is not 

the responder's peer ("ProcessNotPeer"). 

localPermi^. 

sealed copied Permit 

throws FeatureUnavailable, PermitViolated ; 



30 



The responder's local permit. 
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An exception is thrown if either the requester is 
neither the responder nor the place the responder occupies 
("FeatureUnavailable") or an attempt is made to set the 
attribute in a way which' is inconsistent with the Process 
5 Model { "Permit Viola t ed" ) . 

nativePermit : 
sealed copied Permit 

throws FeatureUnavailable, PermitViolated; 



10 



The responder' 8 native permit. 

An exception is thrown if either the requester is 
neither the responder nor a peer thereof 
("FeatureUnavailable") or an attempt is made to set the 
attribute in a way which is inconsistent with the Process 
Model ("PermitViolated"). 

15 permit ; 

sealed readonly copied Permit; 

The responder' s effective permit. 



^ 20 



reaionalP^rmi^; 
sealed copied Permit 

throws FeatureUnavailable, PermitViolated; 



The responder' 3 regional permit. 

An exception is thrown if either the requester is 
neither the responder nor an engine place 
("FeatureUnavailable") or an attempt is made to set the 
25 attribute in a way inconsistent with the Process Model 
("PermitViolated") . 



privat:en;.,ffQo«^. 
sealed readonly Set [Cited] 
so throws ProcessNotPeer ; 
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The set of classes, packages, or both the responder 
holds . 

An exception is thrown if the current process is not 
the responder' s peer ("ProcessNotPeer") . 



S Public Instance O perations 

sealed op (charges; Integer) 
15 throws Permit Inadequate, PermitViolated; 

Increases the responder' s actual charges by the 
10 integer amount (argument "charges") , 

An exception is thrown if the responder' s effective 
permit would be exhausted ( "Permit Inadequate") or the 
current permit forbids operation "charge" 
("PermitViolated") . 



15 restrict J 

sealed op (procedure: Procedure; permit: protected 
Permit) 

throws Exception, PermitViolated, ProcessNotCurrent ; 

Performs the procedure (argument "procedure") under 
^ 20 the temporary permit (argument "permit") and the resulting 
effective permit of the current process, to which the 
procedure's charges accrue. 

An exception is thrown if the procedure does so 
("Exception"), the procedure's performance violates the 
25 effective permit designated above ("PermitViolated"), or 
the requester is not the current process 
( " ProcessNotCurrent " ) . 



sponsor; 

sealed op (procedure: Procedure; permit: protected 
30 Permit) 

throws Exception, PermitViolated, ProcessNotCurrent; 
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Performs the procedure (argument "procedure") under 
the temporary permit ("permit") and the resulting 
effective permit of the responder's owner, to which the 
procedure's charges accrue. The procedure gets access to 
5 the requester's frame and properties, not the responder's. 
An exception is thrown if the procedure does so 
("Exception"), the procedure's performance violates the 
effective permit designated above ( "PermitViolated") , or 
the requester is 
10 not the current process ( "ProcessNotCurrent" ) . 



Private Instance A tt^^bu^■^cl 
20 aOQ ; 

sealed readonly Integer; 



The responder's actual age in seconds. 

15 sliargfiaj. 

sealed readonly Integer; 

The responder's actual charges in teleclicks. 



priority; 
35 sealed Integer | Nil; 



20 



The responder's actual priority, i.e., the 
responder's chosen priority. 



Private Instance Qperatinn fl 
wait ; 

45 unprotected op (seconds: Integer); 

25 Blocks the responder until the requested number of 

seconds (argument "seconds") have elapsed. If the integer 
50 is negative, the operation has no effect. 
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System Instance Qperationa 
live ; 

abstract unprotected op (cause: Exception | Nil) 
throws Exception; 

5 Requested with a nil (argument "cause") to start the 

responder after its creation. If the "canRestart" 
attribute of the permit the responder holds is "true", the 
operation is requested with an exception (argument 
"cause") to restart the responder if the responder fails 
10 due to that exception. 

An exception is thrown if the responder fails to 
catch the exception ("Exception") . 



r^styj^gt^d; 

op (permit: Identifier; isRelocated: Boolean) 
2S 15 PermitReduced|Nil; 

Requested if the responder' s attribute 
"nativePermit", "regionalPermit » , or "localPermit " , once 
set, is set again so as to reduce the responder' s 
capabilities. The identifier (argument "permit") is that 
20 of whichever of these three attributes was set. The 
35 Engine throws the operation's result in the responder' s 

thread if the result is not a nil. The method native to 
this class simply returns a nil. 

The boolean (argument "isRelocated" ) indicates 
25 whether the event leading the Engine to request the 

operation also led the Engine to transport the responder 
to a place, e.g., a purgatory, other than either the one 
the responder occupied or, if the operation is requested 
during the performance of operation "go" or "send", the 
30 responder' 3 destination. In the latter case, operation 
"go" or "send" throws the present operation's result if 
50 not a nil. 
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Note: The responder's ability to perform this 

operation, when the responder's newly -set permit 
is severely restrictive, is limited by the rules 
of process termination. 

5 Adaptation^ 
copy 

A member of "Copy Unavailable" is thrown. 



4.65 Process Exception 
Object (Referenced) 
10 • Exception (Unchanged) 
20 • • Programming Exception 

• • Process Exception 



Class 

ProceasExgepfH^n. 
15 abstract interface (ProgrammingException) () ; 

Permit Inadeoiiat.^ , 

interface (ProcessException) = () ; 

One process tries to charge another so as to exhaust 
20 the latter' s effective permit. 



Condi tionUnavailaM^ . 
^ interface (ProcessException) » (); 

A process manipulates the condition of a resource 
without exclusive use of the resource. 

48 



so 
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ConditionUndpfinA^. 

interface (ProcessException) » () ; 

An identifier purporting to denote a resource's 
condition does not, 

PermitExhausted : 

interface (ProcessException) » () ; 

A process exhausts the permit that the process holds, 
PermitViolatf>HT 

interface (ProcessException) = (); 

A process violates the permit that the process holds. 



25 ProcessNotCurrenf^ . v 

interface (ProcessException) « () ; 



A process requests a feature of other than the 
current member of a class. 

15 ProcessNotP^i^i-. 

interface (ProcessException) « (); 

An object manipulates a process that is not the 
object's peer. 

Resourgeunavailabl,^ . 
20 interface (ProcessException) - () ; 

A resource's use cannot be obtained in the number of 
seconds requested. 



283 



BNSDOCID: <EP 063471 9A2_L 



EP0634 719A2 



10 



2S 



30 



35 



40 



Statelmoroper: 

interface (ProcessException) » (}; 

A process requests a feature while in a state that 
precludes the request . 



5 4.€€ ProaramminQ ExceptioTi 
Ob j ect ( Referenced) 
t5 • Exception (Unchanged) 

• • Proarammina Exception 

Class 

20 10 Proaramm inqExcept ion : 

abstract interface (Exception) - {) ; 



4,67 Qualified Identify at- 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
15 ♦ • Identifier (Ordered^ 

• • • Qualified Identifier 



C3 

QualifiedldentifiAT-. 

sealed interface (Identifier) = () ; 

20 4.68 Random Stream 
Object (Referenced) 

• Stream 

• • Random Strearri 



Cl^SS 

45 25 RandomStreami 

interface (Stream [Integer] ) » (...); 
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Construction 

5 unprotected op (seed: Integer) 

throws Seedlnvalid; 
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5 Makes the responder's seed the integer (argument 

"seed"), makes the responder's "current" attribute a nil, 
and leaves the responder's "next" attribute undefined. 

An exception is thrown if the proposed seed is 
invalid as such ("Seedlnvalid"). 

10 Adaptatipng 
current 

This attribute is an integer. 

This attribute is an integer, and not a nil. 

15 4.69 Real 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Real 

20 Class 

Real : 

sealed interface (Number) » (); 

AdaDtati9^g 
abs 

25 The result is a real. 

add 

The result is a real. 



so 



55 



285 



BNSDOCID: <EP_0634719A2_t> 



EP 0 634 719 A2 



10 



15 



20 



25 



30 



35 



divide 

The result is a real. 
mvlt;ipJi,Y 

The result is a real . 

5 ngqat;e 

The result is a real. 

g]i^tra<?t; 

The result is a real. 



Convergiona 

10 ait 

A bit produces the result of first converting the bit 
to an integer, and then converting the integer to a real, 

A bit string produces the result of first converting 
15 the bit string to an integer, and then converting the 
integer to a real, 

Boolear;^ 

A boolean produces the result of first converting the 
boolean to an integer, and then converting the integer to 
20 a real. 

A character produces the result of first converting 
the character to an integer, and then converting the 
integer to a real. 

46 

25 Integer 

An integer produces the real that is equal to the 
50 integer arithmetically. 
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5 An octet produces the result of first converting the 

octet to an integer, and then converting the integer to a 
real , 

5 OctetString 

An octet string produces the result of first 
converting the octet string to an integer, and then 
converting the integer to a real. 

To 

String 

10 A string that obeys the syntactic rules for the Real 

20 token in Character Telescript produces the corresponding 

real . 

4.70 Referenced 
^ RefQr<gnc^4 

15 Class 
^ Referenced- 

abstract interface {) « (...); 

This class is sealed. 

35 

Public Instance Attrih^^tftff 
20 isProtected* 

sealed readonly Boolean; 

40 

Whether the reference to the responder is protected, 

45 PulpUg Instance Qperationfl 

discard: 
25 sealed op () ; 

» Destroys the responder iff no references to the 

responder remain. 
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isSamg: 

sealed op (reference: protected Referenced) Boolean; 

Returns an indication of whether the referenced 
object (argument "reference") is the responder. 

5 ££2tS£t: 

sealed op () protected Referenced; 

Returns a protected reference to the responder. 

sealed unprotected op ( ) ; 

10 Pushes onto the stack two references to the 

responder, both protected iff the reference used to 
request the operation is itself protected, 

4.71 Resource 
Object (Referenced) 
15 • Resource 



35 Resource : 

interface »(...); 

Constructiion 

unprotected op (condition: Identifier! |Nil; 

conditions: copied Set [Identif ier i ] |Nil) 
throws Condi tionUnde fined ; 



Makes the responder' s native attributes the 
25 like -named arguments (arguments "condition" and 

"conditions") . If either argument is a nil, both must be 
nils, and in that eventuality, the "conditions" attribute 
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comprises one identifier which equals the "condition" 
attribute. The identifier in question is undefined. 

An exception is thrown if the individual condition, 
i.e. the "condition" attribute, is not in the set, i.e. 
5 not in the "conditions" attribute ( "Condi tionUnde fined") 

Public InstangP ft^^r>^K„^.^^ 
condition 
Identifier] 

throws ConditionUnavailable; 

10 The identifier for the responder's condition. 

An exception is thrown if the current process 
attempts to set the attribute and lacks exclusive use of 
the responder ("ConditionUnavailable"). 

25 sanditians: 

15 readonly protected Set [Identifier!]; 

The identifiers for the responder's possible 
30 conditions. 

Public Instanni=> H peral-in nc, 
use : 

^ 20 sealed unprotected op (procedure: Procedure; 

exclusive: Boolean | Nil; 

maximumWait: Integer |Nil; 

^ conditions: copied Set [Identifier!] |Nil) 

Boolean 

25 throws ConditionUndefined, Exception, 

ResourceUnavaileUDle ; 



45 



so 



Obtains use of the responder, performs the procedure 
(argument "procedure"), and then relinquishes the 
responder, even if the procedure fails. The procedure 
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gets access to the requester's frame and properties, not 
the responder's. 

The use is exclusive iff the boolean (argument 
"exclusive") is both present and "true". Iff a set of 
5 identifiers (argument "conditions"), not a nil, is 

supplied, the use is granted only when the responder is in 
one of the conditions the identifiers denote. 

If an integer (argument "maximumWait") is supplied, 
the operation waits for use of the responder no more than 
10 that many seconds. If a nil is supplied instead, the 
operation waits as long as required, possibly forever. 
The operation's result indicates whether, in the former 
case, the responder remained unavailable after the 
indicated number of seconds. 
15 An exception is thrown if the set of conditions is 

cleared or does not equal a subset of the responder's 
"conditions" attribute ("ConditionUndef ined") , the 
procedure throws an exception ("Exception"), or the 
responder's use cannot be obtained in the number of 
30 20 seconds requested ( "ResourceUna vail able" ) . 

4.72 g^legtgr 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Selector 
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25 Class 

Selector; 

sealed interface (Primitive) - (); 

Adapt at iong 
isEoual 

30 Two selectors are equal iff their values are the 

same . 
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4.73 Sfit 

Object (Referenced) 

• Collection 

• • (Verified) 

5 Class 

Set : 

interface [itemClass: Class] 

(Collection [itemClass], Verified) = (,..); 



Parameterized by the class (argument "itemClass-) of 
10 which each item of each member of the subject class is 
20 itself a member. 

initialize; 

unprotected op (items: itemClass ...) 
15 throws IteraDuplicated, Itemlnvalid; 

^ Makes the responder's items the objects (argument 

"items"). 

An exception is thrown if two proposed items are 
equal ( "ItemDuplicated" ) or a proposed item is invalid as 
35 20 such ("Itemlnvalid"). 

Public In.qrangf^ np^y:^h^-^p^ 
di£££££n£e: 

unprotected op (set: protected Set [itemClass]); 

Excludes from the responder and discards every item 
^ 25 that equals an item of the set (argument "set-) . 
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intersection ; 

unprotected op (set: protected Set [itemClass] ) ; 

Excludes from the responder and discards every item 
that does not equal an item of the set (argument "set"). 

unprotected op (set: protected Set [itemClass]); 

Includes in the responder a reference to each item of 
the set (argument "set") that does not equal an existing 
item of the responder. 



10 AgaptatiQns 

include 

An object is included in a set as a new item by first 
25 excluding and discarding any existing item equal to the 

object . 



15 vgyjrfY 

A set is consistent iff no two of the set's items are 
equal . 

4.74 Stack 
Object (Referenced) 
20 • Collection 

• • List (Ordered) 

• • • stasJi 



46 



50 



55 



292 



BNSDOCID: <EP 0634719A2J_> 



EP 0 634 719 A2 



10 



glass 

Stack; 

interface [itemClass: Class] (List [itemClass] ) = 
( . . J ; 

5 Parameterized by the class (argument "itemClass") of 

which each item of each member of the subject class is 
itself a member. 



■ Public Instance Operations? 
pop ; 

10 unprotected op () itemClass 

throws StackDepleted; 



20 



Removes from the responder and returns its top item. 
An exception is thrown if the responder is cleared 
25 ("StackDepleted"). 

15 push : 

unprotected op (item: itemClass); 
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Adds the object (argument "item") to the responder as 
a new item at its top, 

pugti^Xtemg; 

20 unprotected op (items: protected List [itemClass]); 

Pushes onto the responder references to the items of 
the list (argument "items"), a reference to the item at 
position one of the list is placed on top of the 
responder. 
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roll : 

unprotected op (shifts, items: Integer) 
throws Argument Invalid, StacJcDepleted; 

Shifts the topmost items of the responder. 
5 The number of items, «i", participating in the shift 

is given by one integer (argument "items") which shall be 
non-negative. The number of positions, "P», that each 
participating item is to be shifted is given by another 
integer (argument "shifts'-) which may be either positive 
10 or negative, "P« being its absolute value. The 
participating items are shifted toward either the 
^ responder' s top, if this second integer is positive, or 

the responder' s bottom, otherwise. 

To shift the participating items one position toward 
15 the responder 's. top is to change the position of the 

topmost item to -I- and to decrease by one the position of 
each of the other participating items. 

To shift the participating items one position toward 
the responder' s bottom is to make topmost the item whose 
20 position is "I" and to increase by one the position of 
each of the other participating items. 

An exception is thrown if the integer giving "i« is 
negative ( "Argument I nval id " ) or the responder's length is 
less than »I" ("StacJcDepleted"). 

25 swap : 

unprotected op () 
throws StackDepleted; 

Transposes the items at positions one and two of the 
responder. 

An exception is thrown if the responder's length is 
less than two ("StackDepleted"). 
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4.75 stiiftam 

Object (Referenced) 

5 Stream : 

abstract interface [itemClass: Class] - (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

10 Public Instance Attributes 
current : 

abstract readonly itemClass | Nil; 

Either the item the responder produced last, if 
attribute "next" of the responder has been queried but has 
15 not returned a nil having produced all of the responder' s 
items, or a nil, otherwise. 

abstract Boolean; 

Whether the responder has produced all of its items. 

20 next : 

abstract readonly itemClass | Nil 
throws ReferenceProtected; 

Either the next item of the responder, if the 
responder has not produced all of its items already, or a 
25 nil, otherwise. The responder produces another item each 
time this operation is requested. 

An exception is thrown if the responder is protected 
("ReferenceProtected") . 



295 



EP0634 719A2 



4.76 String 

Ob j ect (Referenced) 

• Collection 

• • List (Ordered) 

^ • • • Constrained List (Constrained) 

• • • • string (Cased & Executed) 

Class 

sealed interface 

(ConstrainedList [Character], Cased, Executed) 

(...); 

ConatruetiQT^ 

initialize. 

unprotected op (segments : Object 

/* Character! protected String! */) ; 

Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right. 

Pui?;i<; Tn^tanrP Operationp 
20 substring. 

op (initialPosition, beyondFinalPosition: Integer) 
copied String 
throws Positionlnvalid; 

Returns a copy of the substring of the responder that 
25 comprises the characters at the positions in the range 
["initialPosition", "beyondFinalPosition") . 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid"). 
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Maptat;iQng 

constraint 

The attribute is sealed. The "constraint" 
attribute's "ofClass", "classld", "islnstance" , 
5 "isOptional", and "passage" attributes are class 

"Character", the identifier of class "Character", "true", 
"false", and "byCopy", respectively. 

isMt^er 

One string is after another as if enough characters 
10 were first appended to the shorter string to make the 
shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

isBefore 

15 One string is before another as if enough characters 

were first appended to the shorter string to make the 
shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

20 coov£j:£io£ig 

Bit 

A bit that can be converted to a character that can 
be converted to a string produces that string. 

CalendarTime 

25 A calendar time produces a string describing the time 

represented by the calendar time. 

Character 

A character produces a string whose only item equals 
the character. 
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An identifier produces a string that equals the 
identifier's text. 

Integer 

5 An integer produces a string that obeys the syntactic 

rules for the "Integer- token in a character telescript. 

Pattern 

A pattern produces a string that equals the pattern's 

text. 



10 Real 

20 

A real produces a string that obeys the syntactic 
rules for the "Real" token in a character telescript. 

25 T^i^nmnip^ir 

A telenumber produces the concatenation of a plus 
15 sign {-+"), the telenumber' s country attribute, a space 
(" and the telenumber' s "telephone" attribute . 



A time produces the result of first converting the 
time to a calendar time, and then converting the calendar 
20 time to a string. 



4.77 Teleaddr^^g 
^ Object (Referenced) 

• T^i^^^ciygg? 

^ 25 Teleaddre^g . 

interface - (..,); 



so 
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unprotected op (provider: OctetString! |Nil ; 
location: String! | Nil) ; 

5 Clears the responder's "routingAdvice" attribute and 

makes its other native attributes the like-named arguments 
(arguments "location" and •'provider") . If the latter 
argument is a nil, however, the "provider" attribute is 
made that of the current place's assigned teleaddress. 

10 Public Instance At tributes 

l(?<?at;j,gA: 
St ring! I Nil ; 

Either the string denoting the location of the places 
denoted by the responder, if the latter is assigned or 
15 such a constraint is imposed, or a nil, otherwise. 

provider : 
OctetString! ; 

The octet string denoting, as does a telename's 
"authority" attribute, the provider of the region 
20 containing the places the respohder denotes. 

yoUtinqA<^vj.(;:^: 

List [OctetString!]; 

Octet strings denoting, as does the "provider" 
attribute, and in order of decreasing preference, the 
25 providers of transit regions. 
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Adapt at i(;?ns 

Two teleaddreases are equal according to their native 
attributes . 

5 4.78 Telsnanift 

Object (Referenced) 
• Telename 

Class 

Telename ; 
10 interface = {.,.); 

Cgns^yuct^lon 

init:iali2e: 

unprotected op (authority, identity: 
OctetString! |Nil) ; 

15 Makes the responder's native attributes the 

like-named arguments (arguments "authority" and 
"identity"), if the former argument is a nil, however, 
the "authority- attribute is made that of the current ' 
process' assigned telename. 

20 ?ublic Instance At•_^r-j^t1^^^ 
authority; 
OctetString J ; 

The octet string denoting the authority of the named 
objects the responder denotes. 

25 identity: 

OctetString! |Nil; 

Either the octet string denoting the identity of the 
named object denoted by the responder, if the latter is 
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assigned or such a constraint is imposed, or a nil, 
* otherwise. 

Adaptations 

5 Two telenames are equal according to their native 

attributes. 

15 4.79 Telenumber 

Object (Referenced) 
• T^;^num];^y 

20 10 Class 

Telenumber : 
interface « ( ) ; 

£2iist£ii£ti£a 

initialize: 

15 unprotected op (coxintryAndTelephone : String!; 

^ extension: String! | Nil) ; 

Makes the responder's "extension" attribute the 
like-named argument (argument "extension") and the 
35 responder's other native attributes those of a telenumber 

20 that can be converted to the " count ryAndTelephone" 
argument . 

^ Public Instance Attrjhn^f.^ 

string! ; 

25 The code that CCITT assigns to the country or other 

geographical area in which the instrument the responder 
denotes is located [CCITT] . Each character of the string 
is a numeral (■0"-"9"). 
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extension; 
String! |Nil; 

Either the telephone extension that unambiguously 
identifies the instrument the responder denotes, if the 
5 responder'fl "country" and -telephone" attributes do not do 
that themselves, or a nil, otherwise. Each character of 
the string is a numeral ("0"-"9"), a hyphen ("-"), or a 
space ( " " } . 

telephone : 
10 String!; 

The nunJDer assigned to the instrument the responder 
denotes by the country or other geographical area the 
"country" attribute denotes. Each character of the string 
is a numeral («0"."9-), a hyphen or a space (« ") . 

15 Adaotatio^g 

Two telenumbers are equal according to their native 
attributes, which are equal as if all hyphens ("-") and 
spaces (" ") were first dropped from them, 

20 Converaionfi 

A string that can be produced by converting some 
telenumber produces that telenumber, whose "extension" 
attribute is a nil. 



25 4.80 Xis^ 
^ Object (Referenced) 

• Ticket Stub 
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Class 

Ticket : 

interface (TicketStub) = (..J; 
Congtructior^ 

unprotected op (destinationName : Telename [Nil ; 
destinationAddress : Teleaddress | Nil ; 
destinationClass: Citation | Nil ; 
maximumWait: Integer j Nil; 
10 way: Way j Nil; 

t ravelNotes : Ob j ect | Nil ) ; 

Makes the responder's "desiredWait " and 
"destinationPermit" attributes nils, the responder's other 
attributes the like-named arguments (arguments 
15 "destinationAddress", "destinationClass", 

"destinationName", "maximumWait", "travelNotes" , and 
"way", respectively). 

Public Instance At^^rihl^t^ffff 
desiredWa , 
20 IntegerlNil; 

Either the maximum desired difference in 
seconds—non-negative- -between the time the trip the 
responder defines should be completed and the time the 
trip is requested, if such a constraint is imposed, or a 
25 nil, otherwise. 

destinat ionAddr^^ j g r 
Teleaddress I Nil; 

Either a teleaddress of the destination of the trip 
the responder defines, if such a constraint is imposed, or 
30 a nil, otherwise. 
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destina tionClaag . 
Citation I Nil; 

Either a citation to the subclass of class -Place" of 
which the destination of the trip the responder defines is 
5 a member, if such a constraint is imposed, or a nil, 
otherwise . 

destinationWamP. 
Telename jNil; 

Either a telename of the destination of the trip the 
10 responder defines, if such a constraint is in^osed, or a 
nil , otherwise . 



destina tionPeTTTii-^^ » 
25 Permit I Nil ; 



Either the local permit an agent using the responder 
15 shall have at the agent's destination, if that permit 
differs from the agent's current temporary permit or, if 
the agent has none, the agent's native permit; or a nil, 
otherwise. 



20 Integer I Nil; 



^ Either the maximum permitted difference in seconds 

between the time at which the trip the responder defines 
shall be completed and the time at which the trip is 
requested, if such a constraint is imposed, or a nil, 

45 25 otherwise. The integer, if supplied, shall be 
non-negative. 
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Adaptations 

Two tickets are equal according to their attributes 
native to tickets and ticket st\ibs. 



5 4.81 Ticket fitnh 
Object (Referenced) 
• Ticket Stub 

Class 

Ti9)cet;$t\d); 
10 interface « (...); 



Construction 

initially: 

unprotected op (way: Way | Nil; travelNotes: 
25 Object I Nil); 

15 Makes the responder's native attributes the 

^ like-named arguments (arguments "travelNotes" and "way"). 

Public Instance A^ ^ributg.Q 
t;yave3,Noteff ; 
35 Object|Nil/ 

20 An object for the exclusive use of the agent holding 

the responder. 



way: 

Way I Nil; 



In a ticket, either the way to be taken to the trip's 
25 destination, if such a constraint is imposed, or a nil. 
In a ticket stub, a way back to the trip's origin. 
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Adaptations 
5 isEq^aJ^, 

Two ticket stubs are equal according to their native 
attributes. 

5 4.82 Time 

Object (Referenced) 

• Tiina (Ordered & Unchanged) 
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Class 

Time : 

10 interface (Object, Ordered, Unchanged) « (.,.); 

initialigiq 

Makes the responder the current time, namely, that at 
the current place, 

15 Public Tnstangft Qp ^ration g 
adj^s^: 

op (seconds: Integer) Time- 
Returns a time that is the requested number of 
seconds (argument -seconds-) after the responder and that 
20 Identifies the same permanent and seasonal offsets. 

No££: If the integer is negative, the time returned 

precedes the responder. 

interval ' 

op (subtrahend: Time) Integer; 

Returns the arithmetic difference in seconds between 
the responder, which is the minuend, and the time 
(argument -subtrahend"), which is the subtrahend. 
Hatfi: The result measures the distance between two 

absolute points in time. 
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A<^apt;at;iQnig 
isAfter 

One time is after another iff the absolute point in 
time that the first identifies follows the absolute point 
5 in time that the second identifies. 

One time is before another iff the absolute point in 
time that the first identifies precedes the absolute point 
in time that the second identifies. 

10 isEoual 

Two times are equal iff neither is before the other. 

Cgnvergiona 

Ca;endayTJ.p\^ 

A calendar time produces a time denoting the same 
15 point in time and the same permanent and seasonal offsets. 

4.83 Trip Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • "Trip Exception" 

20 Class 

TripExcepti^^- 

abstract interface (Exception) = (...); 



Cop^tyyctiQn 

initialize; 

^ 25 unprotected op (ticketStub: TicketStub) ; 

Makes the responder's native attribute the like-named 
argument (argument "ticketStub") . 
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PestinationUnavailahl^^ 
interface (TripException) = (); 

A trip's destination is unreachable because the 
Network is partitioned. Thus the destination may be 
5 reachable in the future. 



DestinationUnknovn > 
15 interface (TripException) = {); 

A trip's destination cannot be identified and thus is 
unreachable . 



10 OccupancvDenief^ ; 

interface (TripException) » (); 

A trip's destination denies the agent occupancy and 
therefore arrival. 



30 TicketExPir^ra. 

15 interface (TripException) = {); 



A trip's destination cannot be reached in the number 
of seconds requested by the "maximumWait " attribute of the 
ticket for the trip, 

WavUnavailahl*^. 
20 interface (TripException) = (); 

A trip's origin lacks the way required for the trip. 

Public Instance AttribufRa 
ticketst^uhr 
sealed TicketStub; 

25 The ticket stub resulting from the unsuccessful trip. 
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isEcrual 

Two trip exceptions are equal according to their 
native attributes. 

5 4.84 Unchanged 
Unchanae4 

Class 

Unchanged: 
abstract interface ( ) = { ) ; 

copy 

A copy of an unchanged object is the original. 

25 4.85 Unexpected Exceotirtn 

Object (Referenced) 
15 • Exception (Unchanged) 

• Prograicaning Exception 

• • Kernel Exception 

• • • Execution Exception 

• • • • "Unexpected Exception" 
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20 Class 

Unexpect edExcfent i nn ■ 

interface (ExecutionException) - (...); 

Construction 

initialize; 

25 unprotected op (exception: Exception); 

Makes the responder's native attribute the like-named 
argument (argument "exception") . 
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Public Instance Attri hnt-^f, 
readonly Exception; 



The exception, which a feature did not declare but 
5 nevertheless threw, that is the cause of the responder. 



4 , 86 Unmoved 
Unmoved 



Class 

Unmoved ; 

20 10 abstract interface () - ()/ 

4.87 Verified 



Verified^ 

15 abstract interface () = {..,); 



Public Instance Qp^^^hfoflg 
verify: 

35 abstract op () Boolean; 

Returns an indication of whether the responder is 
20 consistent. 



4.88 VJay 

Object (Referenced) 
• Way 



25 Wav: 
50 interface «(,..); 
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Construction 

initialize: 
unprotected op ( 

name : Telename | Ni 1 ; 
5 means: MeemslNil; 

authenticator : Authenticator | Nil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "authenticator", "means", 
and "name") . 

10 Public Instance At tributi= >.c; 
authenticator; 
Authenticator | Ni 1 ; 



Either the authenticator to be used to enter the 
25 region through which the way passes, if such a constraint 

15 is imposed, or a nil, otherwise. 



means : 
Means I Nil; 



Either the means by which the region through which 
the way passes is to be accessed, if such a constraint is 
20 imposed, or a nil, otherwise. 

^ Telename I Nil; 

Either the telename of the region through which the 
way passes, if such a constraint is imposed, or a nil, 
25 otherwise. 



Adaptatiny^g 
50 i3E;qy9^1 
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Two ways are equal according to their native 
attributes . 
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5. TELESCRIPT 5YNTJ^X 

A "telescript" is an encoding of a procedure. The 
abstract syntax of telescripts in general, and the 
concrete syntax of character and binary telescripts in 
particular, are defined in this section of this appendix, 
HaJifi: Character telescripts are used by people, binary 

telescripts by machines, e.g., when transporting 
objects between them. A binary telescript is 
almost always considerably fewer octets in 
length than the functionally equivalent 
character telescript. 
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5.1 Te],?gqyipt: 

A telescript is a series of tokens comprising, first, 
a preface and, second, the procedure that the telescript 
encodes. The preface identifies the major and minor 
versions of the Instruction Set to which the telescript 
conforms. 

A telescript obeys the syntactic, and accompanying 
semantic, rules below. Given in BNF, the rules surround 
optional tokens by brackets ("[" and "]'•): 
Telescript Preface Procedure 

[ExecutedObject Body] 
Bit I BitString | Boolean | 
Identifier | Integer | 

Octet I OctetString | Mark | 
Nil j Procedure | Qldentifier | 
Real I Selector | String 

- BitZero I BitOne 
« BooleanFalse | BooleanTrue 

- Modif ierDemarcate | 
Modi fierGet Class [ 
Modif ierGetProperty | 



Body 

25 ExecutedObject 
Character 

Modifier | 



Bit 
Boolean 
Modifier 
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Modi fierMent ion | 
Modif ierSetAttribute | 
Modi fierSet Property | 
5 ModifierSetVariable | 

Modif ierUseStack 
Selector ::= SelectorBreak ] 
SelectorClient | 
SelectorContinue | 
10 SelectorEscalate j 

SelectorPlace | 
SelectorProcess | 
SelectorSelf | 
SelectorSucceed 



15 A teleecript can include comments, the provision for 

which is considered among the syntactic rules. A 
"comment" is a string that does not affect the procedure 
the telescript encodes. One or more comments can appear 
before the script's first token, after its last, and 
20 between any two adjacent tokens. 

Mq£S: a comment usually describes an aspect of a 

telescript to a human being. 
Note: The major and minor versions of the Instruction 

Set as defined in this appendix are identified 
40 <"0") and eight ("8-), respectively. 

5.2 Character Teleagy^ , j ;>^ 

A "character telescript" is a procedure encoded as a 
45 string. The abstract syntactic rules for telescripts in 

general are made concrete for character telescripts in 
30 particular in this section. 

Each token in a character telescript is one or more 
characters. The character telescript is obtained by 
concatenating the tokens, and thus the characters, and by 
inserting break characters between tokens. 
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A break character is a space (" a horizontal tab, 
or a line feed. One or more such characters can appear 
before the first token, after the last, or between any two 
adjacent tokens, in the last case, at least one must 
5 appear if the two adjacent tokens comprise only numerals 
("0"--9") and letters, except when both tokens are either 
"BinDigit" or "hexDigitPair" . 

Terminals beginning with number sign {••#") and the 
keyword "telescript- are case-insensitive. While 
10 upper-case characters appear in this appendix, lower-case 
characters, or a mix of the two, can be used in 
programming . 

5.2.1 Preface and Comm^ni- 

IS A preface obeys these rules; 

Preface : telescript Version 
Version : :« numerals : numerals 

The first "numerals" identifies the major version of 
the Instruction Set to which a character telescript 
20 conforms, the second "numerals" identifies the minor 
version. 

Comment 

A comment obeys this rule: 

Comment ::- /* comment 1 */ | // comment2 
25 Nfitfi: The syntax rules for comments are those of the 

C++ programming language. 



5.2.2 Executed rth-f^r;^,f| 

45 ait 

A bit obeys these rules, which individually encode 
3 0 the bit's values: 



50 



BitZero : :« #b ' 0 
BitOne : :c #b ' 1 
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BitStrina 

A bit string obeys these rules: 

BitString #b " BinDigits " 
BinDigits : := [BinDigit BinDigits] 

5 The i* "BinDigit" represents the bit at position "i" 

of the bit string. 

Boolg^^ 

A boolean obeys these rules, which individually 
encode the boolean' s values: 
10 BooleanFalse ::= #false 

BooleanTrue #true 

Character 

A character obeys this rule: 

Character ::= #c ' characters ' 

15 "characters" shall stand for one character. Each 

character stands for itself, with exceptions as defined 
for class "String". 

Identifi,ey 

An identifier obeys this rule: 
2C» Identifier ::= identifier | ] 

"identifier" is the identifier's text. The right 
square bracket ["] »] denotes operation "new". 



Integer 

45 An integer obeys this rule: 

Integer ::» [-] numerals 



25 



Mark 

A mark obeys this rule: 

Mark #tnark | [ 
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Note: Left square bracket ["["] is provided for 

possible use, by convention, with right square 
bracket (see token "Identifier" above). 



MQ^jfier 

5 A modifier obeys these rules, which individually 

encode the modifier's values. 
Modif ierDemarcate 



Modif ierGetClass 
Modif ierGetProperty 
10 ModifierGetVariable 
Modif ierMent ion 
Modi f i er S e t At t r ibu t e 
Modif ierSet Property 
Modif ierSetVariable 
15 ModifierUseStack 



® 
$ 
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A nil obeys this rule: 
Nil #nil 

Octet 

An octet obeys this rule: 

Octet ::a #o ' hexDigitPair ' 

The MSB of "hexDigitPair" represents Bit 7 of the 
octet, the LSB represents Bit 0. 



OctetStriT^g 
25 An octet string obeys these rules: 

OctetString ::= #o " HexDigitPairs " 
HexDigitPairs ::« [hexDigitPair HexDigitPairs] 

The first "hexDigitPair" represents the octet at 
position one of the octet string, the second that at 
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position two, etc. The MSB of each "hexDigitPair" 
represents Bit 7 of that octet, the LSB represents Bit 0. 

Procedure 

A procedure obeys this rule: 
5 Procedure ; : = { Body } 

Qualif iedldentif ier 

A qualified identifier obeys this rule: 
Qldentifier : := identifier :: identifier 

The first "identifier" represents the text; the 
10 second represents the qualifier. 
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Real 

A real obeys these rules: 

Real : : = Number [Exponent] 
Number : : = Integer . numerals | 
Integer . | 
numerals 
Exponent : : « E Integer 
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The real's integral part is either the "Integer" in 
"Number", if present, or zero, otherwise. The real's 
20 fractional part is either "numerals", if present, or zero, 
otherwise. The "Integer" in "Exponent", if present, is a 
power of ten. 

?^3,ggtor 

A selector obeys these rules, which individually 
25 encode the selector's values: 



30 



SelectorBreak 
SelectorClient 
Se 1 ec torCont inue 
SelectorEscalate 

SelectorPlace 



= #brea)c 
= #client 
« #continue 
= #escalate 
«= #here 
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SelectorProcess 
SelectorSelf 
SelectorSucceed 



- #process 

- #self I * 

- #succeed 



A string obeys this rule: 
String ::- [#c) 



characters 



"characters" stands for zero or more characters. 
Each character stands for itself, except that a reverse 
slash ("\") and four hexadecimal digits ("O"-"^", "A"-"?") 
10 stand for the character whose Unicode code is the unsigned 
integer the digits represent, a character pair in Table 
A. 6 for the indicated character. 



25 



30 



35 



40 



TABLE A. 6 



15 



20 



1 Character seouen^^^ 


Sinale Char^<?te]r 


\b 


Backspace 


\f 


Form feed 


\n 


Line feed (newline) 


\r 


Carriage return 


\t 


Horizontal tab 


\v 


Vertical tab 


\" 


Quotation mark (""") 


W 


Reverse slash ("\") 
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5-2.3 Other Non-terminal 

characterfl 

25 Zero or more characters, each a printing character or 

a space {- "). a quotation mark (-) shall be preceded by 
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a reverse slash ("\") . A reverse slash either shall be a 
part of a character sequence in the table found under 
token "String* above, or shall precede four hexadecimal 
digits. 

5 comment 1 

Zero or more characters, not including an asterisk 
immediately followed by a slash (•**/**). 
NfitS: "commentl" can encompass "/*" or "//" without 

special meaning, and thus can encompass a 
10 " comment 2". 

Zero or more characters, not including a line feed. 
Note : "comment2" can encompass "*/"# or "//" 

without special meaning, and thus can encompass 
^5 ^ a "commentl". "comment2" cannot be followed on 

the same line by other tokens, since it would be 
considered to encompass them. 



25 



30 



35 



h^)cpd,q;;^:Pa;i,r 

A pair of hexadecimal digits ("C'-^g", "A"-"F") 

Characters constrained as is the text of an 
identifier. 



^ numerals 

One or more numerals ("0"-"9") 



45 



50 



25 5.3 PAnayy T^lespri pr 

A "binary telescript" is a procedure encoded as an 
octet string. The abstract syntactic rules for 
telescrlpts in general are made concrete for binary 
telescripts in particular in this section. 
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Each token in a binary telescript is one or more 
octets. The binary telescript is obtained by 
concatenating the tokens and thus the octets. 

5.3.1 Preface and Comment. 

5 Pr^gagg 

A preface obeys these rules: 
Preface : : » Version 

Version : : - unsignedNumber unsignedNumber 

The first and second "unsignedNumber" identify the 
10 major and minor versions, respectively, of the Instruction 
Set to which a character telescript conforms. 



A comment obeys this rule: 
25 Comment : : - tag unsignedNumber characters 

15 The "unsignedNumber" is the number of octets to be 

recognized as characters. 



5.3,2 Executed Qt7iftgt;fl 

lit 

A bit obeys these rules, which, individually encode 
20 the bit's values: 

BitZero ; :« tag 
BitOne : : ■ tag 



Bi,tgtyiqg 

A bit string obeys these rules: 

BitString tag unsignedNumber unsignedNumber 
^ Octets 

Octets [octet Octets] 
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The first "unsignedNumber" is the number-in the 
range [1, 8] -of bits of the bit string in the last octet; 
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the other bits in that octet have no significance and are 
undefined. The second "unsignedNuraber" is the number, 
"n", of occurrences of the token "octet" in the token' 
"Octets". If the octets are numbered in [l, n] , the bit 
5 whose position in the bit string is "i" is Bit (7-((i-l) 
mod 8)) of the octet numbered (l+{i-l)/8). 

Boolean 

A boolean obeys these rules, which individually 
encode the boolean' s values: 
10 BooleanFalse tag 

Boolean True : :« tag 

Chayagter 

A character obeys these rules. A general and a 
special encoding are defined. The latter shall be used 
15 for eight-bit characters: 

Character .-.-o GeneralCharacter | 
Special Character 

GeneralCharacter ::= tag octet octet 

SpecialCharacter : : . tag octet 

20 The one or two octets encode unsigned the integer 

that is the character's Unicode code, in the special 
encoding, the MSB and LSB of the integer are those of the 
octet. In the general encoding, the MSB and LSB of the 
integer are the MSB of the first octet and the LSB of the 

25 second, respectively. 

IdentifieT^ 

An identifier obeys these rules. One general and two 
special encodings are defined. One of the latter shall be 
used iff the text of the identifier equals that of the 
30 identifier of a predefined class or feature: 
Identifier General ID | 

PredefinedClassID | 
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General ID 
Predef inedClassID 
Prede f iriedFea t ure ID 



Predef inedFeature ID 
= tag unsignedNumber characters 
= tag unsignedNumber 
- tag unsignedNumber 



5 In the general encoding, "unsignedNumber" and 

"characters" represent the text directly. The former is 
the number of octets to be recognized as the latter. In a 
special encoding, "unsignedNumber" represents the 
identifier's text indirectly, by a code drawn from one of 
10 the tables in section S.4. 



20 
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Integer 

An integer obeys these rules. One general and 
several special, encodings are defined. The latter shall 
be used for -1, 0, and +1: 



15 



20 



25 



Integer 
General Integer 
Speciallnteger 



IntegerMinusOne 
IntegerZero 
IntegerPlusOne- 



General Integer | Speciallnteger 
tag signedNumber 
IntegerMinusOne | 
IntegerZero | 
IntegerPlusOne 
» tag 
= tag 
- tag 



The signedNumber is the integer. 

A mark obeys this rule: 
Mark : ; = tag 



45 



SO 



Modifier 

A modifier obeys these rules, which individually 
encode the modifier's values: 
30 ModifierDemarcate ::o tag 
Modif ierGetClass : : = tag 
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5 



Modi fierGet Property 
Modif ierGetVariable 



tag 
tag 
= tag 
= tag 
= tag 
= tag 
= tag 



10 



Modi f ierMent ion 
Modif ierSetAttribute 
Modif ierSetProperty 
Modif ierSetVariable 



Modif ierUseS tack 



15 



Nil 



10 



A nil obeys this rule: 
Nil : tag 



20 



Octet 

An octet obeys this rule: 
Octet tag octet 



25 



The MSB of "octet" represents Bit 7 of the octet, the 
15 LSB Bit 0. 

OctetStrina 

An octet string obeys these rules: 



20 The "unsignedNuraber- is the number of occurrences of 

"octet" in "Octets". The first "octet" in "Octets" 
represents the octet at position one of the octet string, 
the second "octet" that at position two, etc. The MSB of 
each "octet" represents Bit 7 of that octet, the LSB 

25 represents Bit 0. 



OctetString ::= tag unsignedNumber Octets 
Octets [octet Octets] 
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Procedure 

A procedure obeys this rule: 

Procedure ::= tag unsignedNumber Body 
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The "unsignedNumber" encodes the number of 
occurrences of "ExecutedObject " in "Body", each of which 
encodes an item of the procedure. The items are given in 
order of increasing position within the procedure. 

5 Qualifiedldentifier 

A qualified identifier obeys this rule: 

Qldentifier tag Identifier Identifier 

The first "Identifier" represents the text, the 
second represents the qualifier. - 

20 10 Real 

A real obeys this rule: 

Real tag signedNumber signedNumber 



10 



15 



2S 
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The first "signedNumber" is a mantissa, "m", the 
second 

IS an exponent, "e". The real is m x lO*. 
Selector 

A selector obeys these rules, which individually 
encode the selector's values: 



35 SelectorBreak 
20 Selector Client 

Selector Continue 
Selector Escalate 
Selector Place 
Selector Process 
25 Selector Self 

Selector Succeed 



:« tag 
:= tag 
tag 
:= tag 
:= tag 
:= tag 
:= tag 
= tag 



String 

A string obeys this rule: 

String tag unsignedNumber characters 
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The "unsignedNumber" is the number of octets to be 
recognized ae characters. The syntax and semantics of the 
octets shall conform to ISO/IEC 10646 [10646] compaction 
method 5, except that the characters thereby represented 
5 shall be limited to those of Unicode. 

Nq^: If the string comprises only ASCII characters, 

"characters" comprises their ASCII 
representations, one character per octet. Bit 7 
of each octet being zero. 

10 5.3.3 Other Non-terminal a 

characters 
Zero or more octets. 



From one to five, »N" , octets encoding an integer, 
15 "I". The encoding, -E\ of "l" is either unsigned, if the 
use of number insists that "I" be non-negative, or twos 
complement, otherwise. Given "I", -N" shall be as small 
as possible. 

"E" is determined as follows. 
20 • If the value of the first octet is in the range of 
lO, BFJ , "N" is one and the MSB and LSB of "E" are 
35 Bit 7 and Bit 0 of that sole octet. 

• If the first octet is E0,„ E4,„ or E6,„ "N" is 

2, 3, 4, or 5 and the MSB and LSB of "E" would be Bit 
25 7 of the first octet and Bit 0 of the last octet if 

the first octet were made 00|<s. 

• If the first octet is El^,, E3,,, E5,,, or E7,„ N is 2, 

3, 4, or 5 and the MSB and LSB of »E" would be Bit 7 
of the first octet and Bit 0 of the last octet if the 

30 first octet were made FFi^. 

Nstfi: The first octet's values in the ranges of [CO,^, 
DF,^] and [E8,a, FFj^] are reserved. 



so 



octet 
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One octet. 
gi,qne<j^uml?^jir 

"number", where "I" can be positive or negative, and 
thus where "E" is signed (see above) . 
5 iiatfi: If "N" is one, "I" is in the range [-64, 127], 

If "N" is two, "I" is in the range (-128, 127). 
If "N" is three, "I" is in the range (-32768, 
32767]. If "N« is four, "I- is in the range 
[-8388608, 8388607] . If -N" is five, "I" is in 
10 the range C-2147483648, - 2147483647] . 

tag 

"signedNumber", where the tag's meanings are given in 
the next section. 



una ionedNumber 

15 "number", where "I" is non-negative, and thus "E" is 

unsigned (see above) , 

Ufitft: If "N- is one, "!« is in the range [0, 191] . If 

"N" is two, "I" is in the range [0, 255]. If 
«N" is three, "I" is in the range [0, 65535] . 
20 If -N" is four, «I« is in the range [0, 

16777215] . If »N- is five, "I" is in the range 
^ (0, 42949672951 . 

5.4 wumeric <:Q<aga 

Binary telescripts make use of the following numeric 
40 25 codes. 

5.4.1 Predefined CI^ssp^c^ 

Table A. 7 assigns identifier codes to the predefined 
4S subclasses of class "Executed". 



TABLE A, 7 
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15 



20 



25 



30 



35 



10 I 10 



11 



12 



13 



14 



15 I 15 



16 



Bit 



BitString 



Boolean 



Character 



Identifier 



Integer 



Mark 



Modifier 



Nil 



Octet 



OctetString 



Procedure 



Qldentif ier 



Real 



Selector 



String 



Table A. 8 assigns identifier codes to the other major 
predefined classes . 



40 



45 



20 



TABLE l.a 



[20 


Agent 1 


21 


Association 


22 


Attribute 




Authenticator 

' •■ 
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40 20 



46 





1 


CalendarTime 


1 25 


Cased 




26 


Citation 


27 


Cited 




\ 


Class 1 




1 


ClassDefinition | 


30 


ClassException 


31 


Collection 


32 


Collect ionExcept ion 


33 


Constrained 


34 


ConstrainedDictionary 


35 


ConstrainedList 


36 


ConstrainedSet 


37 


Constraint 


38 


Contact 


39 


Contacted 






Dictionary 




41 


Exception 




42 


Executed 




43 


ExecutionException j 




44 






45 




Feature R 




46 


Hashed 




47 


Implementation 
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40 20 





1 46 


Interchanged j 




1 49 


Interface | 


1 


KemelException 


j 


51 


Lexicon 


52 


List 


S3 




Means 


54 


Me e t ingExcept ion 


55 


MeetingPlace 


56 




Method 




Mi s c e 1 1 aneousExcep t ion 


58 


Named 


59 


Number 1 


60 


Ob j ect 


61 


Operation | 


62 


Ordered 


63 


Package 




Pattern 




65 


Permit 




66 


Petition 




67 


Petitioned 




68 


Place 




69 


Primitive 




70 


PrimitiveException 




71 


Process 
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50 



72 



73 



74 



75 



76 



77 



78 



79 



80 



10 H 61 



82 



15 



83 



84 



85 



86 



87 



88 



89 



90 



20 I 91 



92 



93 



94 



ProcessExcept ion 



ProgrammingException 



Randoms t ream 



Referenced 



Resource 



Set 



Stack 



Stream 



Teleaddress 



Tele name 



Telenumber 



Ticket 



TicketStub 



Time 



TripException 



Unchanged 



UnexpectedException 



Unmoved 



Verified 



Way 



Table A. 9 assigns identifier codes to the minor 
25 predefined classes. 
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15 



15 



« 20 





TABLE A.? 


100 


Permitlnadequate H 


101 


Argument Invalid 


102 


ArgumentMissing 


103 


At tr ibut eReadOnly 


104 


ClassAbstract 1 


105 


ClassUnavailable | 


106 


ClassUndef ined 


107 


ClassSealed 


108 


Condi t ionUna va i 1 ab 1 e 


109 


Condi t ionUnde f ined 




ConversionUnavailable 


111 


CopyUnava i 1 abl e 


112 


DestinationUnavailable 


113 


Dest inat ionUnknown 


XX. 


DivisionByZero 


115 


- 


116 


Escalationlnvalid 


117 


FeatureRedef ined 


118 


FeatureSealed 


119 


FeatureUnavailable 


120 


FeatureUnde fined 


121 


InternalException 


122 


I temDupl icated 
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^ 20 



123 


Itemlnvalid 




124 


KeyDuplicated 




125 


Key Invalid 


126 


LoopMissing 




127 


MarkMisaing 




128 


MeetingDenied 




129 


MeetingDuplicated 




130 


Meetinglnvalid 




131 


MixinOisallowed 




132 


ObjectsUnpaired 




133 . 


ObjectUninitialized 




134 


OccupanyDenied 


135 


Passage Invalid 


136 


Patternlnvalid 


1 137 


Permit Exhausted 


138 


Permitviolated 


139 


PetitionExpired 


140 


Positionlnvalid 


141 


Proce s BNot Cur rent 


142 


ProcessNotPeer 


143 


PropertyUndefined 


144 


ReferenceProtected 


145 


ReferenceVoid 


146 


ResponderMisaing 
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5 



10 



II ^^"^ 


Resultlnvalid 1 


1 148 


ResultMissing 


149 


SelectorDuplicated 


150 


StackDepleted 


151 


Statelmproper 


152 


Superclasseelnvalid 


153 


TicketExpired 


f 


VariableUndefined 




WayUnavailable 

• 


179 


ResourceUnavailable 


180 


Seedlnvalid 



5.4.2 Predefine d Featurga 

Table A. 10 assigns identifier codes to the predefined 
operations. 



15 
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TABLE A.ig 


1 


abs 


2 


add 


3 


adjust 


4 


and 


s 


catch 


S 


ceiling 


7 


charge 


8 


clear 
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9 


convert 9 


10 


copy- 




11 


difference 




12 


discard 




13 


divide 




14 


do 




15 


drop 


16 


either 


17 


entering 


18 


examine 


19 


exclude 




20 


exiting. 




21 


finalize 


22 


cxno 


23 


floor 


24 


get 


25 


globalize 


26 


go 


27 


if 


23 


include 


29 


initialize 


30 


intersection 


31 


interval 
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5 







TABLE A. 10 






32 


isAfter 


10 




33 


isBefore 












34 


isEc[ual 


15 




35 


islnstance 


5 


36 


isMember 












37 


isSame 


20 




38 


isSubclass 












39 


live 






40 


localize 


OK 

do 




41 


loop 






42 


makeClasses 






43 


makeLower 


30 




44 


makeUpper 






45 


meet 




15 


46 


meeting 


35 




47 


modulus 






48 


multiply 


40 




49 


negate 






50 


new 




20 


51 


normalize 


45 




52 


not 






53 


or 






54 
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TABLE A. 10 1 


55 


part All 1 


56 


parting H 


57 


pop 1 


58 


protect 




59 


push 




II 


pushi terns 




1 61 


quotient 




62 


ref 


63 


rekey 




64 


repeat 




65 


reposition 


66 


restrict 


67 


roll 


68 


round 


69 


select 


70 


send 


71 


set 


72 


stream 


73 


substitute 


74 


substring 


75 


subtract 


76 


swap 


77 


terminate 



so 
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15 



20 





T2iQT IT A in 
i.AUijt A. 10 


78 


throw 


/ J 


transpose 


AO 


truncate 


81 


unxon 


82 


use 


83 


verify 


84 


wait 


85 


while 


86 


max 


87 


min 


Table A. 11 assigns identifier codes to the predefined 
attributes . 


1 TABLE A.;; ] 


89 


address 


90 


agentClass 


1 


agentName 


1 92 


allowance 


1 93 


arguments 


94 


authenticator 1 


95 


author 


96 


authority 


97 


brand 
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j, 98 . 


catiCharge 


99 


canGo 


100 


canProcreate 


101 


canRestart 


102 


canSend 


103 


canTerminate 1 


104 


citation 1 


105 


class 1 


106 


classFeatures 


107 


classXd 


108 


classMethods 


109 


condition 


110 


conditions 


111 


constraint 


112 


contacts 


113 


country 


114 


current 


115 


day 


116 


dayOfWeeJc 


117 


dayOfYear 


118 


deadline 


119 


desiredWait 


120 


dest inationAddress 



so 
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TABLE A. 11 1 


121 


destinationClass | 


122 


uc 9 u Xiid L. X diname 




123 


u.esuxndCxonr'exTnx c 




124 


digest 




1 9^ 


QSC 






exception 






except ions 




128 


cjyuensxon 




129 


I roniMe c no as 


130 


nasn 




X J X 


hour 




132 


identity 


133 


i imp 1 ement a t i on 


134 


instancePeatures 


135 


ins t cuiceMe t hods 




interface 


137 


isAbstract 


138 


is Done 


139 


is Lower 


140 


isOptional 


141 


isProtected 


142 


isPublic 


143 


isSet 
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isUpper 






key 




1 A C 


length 




1 A T 
<L*t / 


location 




1 A A 


major Edit ion 




1 A O 


maximumWait 






means 






minorEdition 




minute 






month 






name 




X^ ^ 


next 


X90 


ofClass 






passage 




158 


permit 




159 


^X XUX XL.\r 




160 


privateClasses 




161 


procedure 1 




162 


properties 




163 


provider 




164 


puhlicClasses 


1 X65 


result II 


I- 


routingAdvice 11 
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46 









167 


sealedClassFeatures 




168 


sealedlnstanceFeatures 




I 169 


setMethods 




170 


second 


5 


171 


size 




172 


subject 






173 


subjectClass 




174 


sub j ectName 




175 


subjectNotes 


10 


176 


superclasses | 




177 


telephone 




178 


ticketstub 




179 


title 




180 


toMethods 


15 


181 


travelNotes 




182 


value 




183 


variables 




184 


vocabulary- 




185 


way 


20 


186 


year 




187 


zone 



Note: "islnstance" is not listed as an attribute 

because it is also an operation. 
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Table A. 12 assigns codes to the forms of passage. 



10 



IS 





TABLE A. 12 | 


191. 


byCopy j 


192 


byProtectedRef 


193 


byRef 


194 


byUnprotectedRef 



20 



5.4.3 Executed Obiect Encodincrp 

TaUsle A. 13 assigns codes to general -purpose 
encodings . 



25 10 
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35 



40 
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TABM A,13 1 


1 


^. =d 


2 


BitString 1 


3 




4 


GeneralCharacter 


5 


Identifier 


6 


General Integer 


7 


Mark 


8 




9 


Nil 


10 


Octet 


11 


OctetString 


1 


Procedure 


1 


Qualif iedldentifier 
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TABLE A. 13 1 


14 


Real 


15 




16 


String 



Note : These tags are the codes for the corresponding 

5 predefined classes. 

Table A. 14 assigns codes to special -purpose encodings 
of a basic nature. 



30 





0 


Conunent 


-1 


BitZero 


-2 


BitOne 


-3 


BooleanFalse 


-4 


BooleanTrue 


-5 


SpecialCharacter 


-6 


Predef inedclassldentifier 


-7 


Predef inedFeatureldentif ier 


-8 


IntegerMinusOne 


-9 


IntegerZero 


-10 


IntegerPlusOne 



20 Table A. 15 assigns codes to special -purpose encodings 

of modifiers. 
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25 10 



30 



20 



- 1 ? 


Modi f ierOemar cat e 




-13 


riou X i. X eroe u L>x a s s 




-14 


Modi f ierGet Property 




-15 


Modif ierGetVariable 




-16 


Modif ierMention 




-17 


Modif ierSetAttribute 




-18 


Modif ierSet Property 




-19 


Modif ierSetVariable 




-20 


Modif ierUseStack 


Table A. 16 assigns codes to special -purpose encodings 
of selectors. 






TABI^ A,:^^ 


-21 


SelectorBreak 


-22 


SelectorClient 


-23 


Selectorcontinue 


-24 


SelectorEscalate 


-25 


SelectorPlace 


-26 


SelectorProcess 


-27 


SelectorSelf 


-28 


SelectorSucceed | 


I Syntax of Module 

A "module", as the term is used here, is a string 



that encodes one or more interfaces, the identifiers of 
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10 



the classes of which those interfaces are parts, and, 
finally, an identifier for the module itself. 

Throughout Section 6, the term "identifier" 
implicitly refers to the text of an instance of class 
5 "Identifier", rather than to the instance as a whole. 
Note : A module constructed as described below is a 

High Telescript module as well. Any rule below 
that makes this statement false is a 
documentation error. 

10 6.1 G^ney^Jt gt^yuc^:uyQ 

A module is a series of tokens obeying the syntactic, 
and accompanying semantic, rules below. Given in BNF, the 
rules surround optional tokens by brackets ("[" and "] ") . 
In addition, a module can include comments of the sort 
15 permitted in a character telescript. The provision for 
such comments is considered among the syntactic rules 
governing the module . 

Each token is one or more characters. The module is 
30 obtained by concatenating the tokens, and thus the 

20 characters, and by inserting between tokens break 
characters of the sort permitted in a character 
telescript. 

Keywords, e.g., "module", are case-sensitive. While 
upper-case characters are used below to describe modules 
25 in general, lower-case characters are used in Section 7 
and throughout this appendix to construct a module. 



20 



25 



35 



40 



45 
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6.2 Detailed Structure 

A module exhibits the* following detailed structure, 

6.2.1 MQduls 
30 Module 

A module obeys these rules: 

Module ::= identifier : MODULE « 

(Interfaces) 
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Interfaces 
[Interfaces] 



:= identifier : Interface; 



10 



15 



20 



25 



30 



35 



40 



45 



The module is denoted by the identifier that begins 
the module, and encodes the interfaces, each that of the 
5 class whose identifier immediately precedes the 
identifier. 

Any interface can define operation "initialize" as it 
pertains to members of the interface's particular class. 
A definition is implied, furthermore, if none is stated: 
10 either "initialize: op ();", if the class in question is a 
mix-in, or the definition for the flavor among the class' 
interface superclasses , otherwise . 



6.2.2 Interface 
Interface 
15 An interface obeys 

Interface : :s 



) 

20 Formal Parameters 
Forma 1 Par ame t erfltoup 
Superclasses 
Definitions 
Def initionGroup 



25 



Access 
Responder 
Identifiers 
Definition 



these rules: 

= [SEALED I ABSTRACT] INTERFACE 
" [ " Formal Parameters " ] " ] 
[Superclasses] « ( [Definitions] 

ParameterGroup [ ; 
Identifiers : CLASS 
( [ClassSpecifiers] ) 
Def initionGroup ; [Definitions] 
[Access] [Responder] 
Identifiers : Definition 
PUBLIC I PRIVATE | SYSTEM 
INSTANCE I CLASS 
identifier [, Identifiers] 
SEALED I [SEALED | ABSTRACT] 



30 Feature 



50 



An interface's encoding can be parameterized. In 
such an encoding, one or more "formal class parameters" 
each an identifier, are introduced, and can be used in 
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most places the interface requires class identifiers (see 
token "ClassSpecifier" below) , The interface is as if the 
identifier of class "Object" were used instead. Formal 
class parameters defined alike are grouped at their 
5 introduction. 

Zero or more features, each denoted by an identifier, 
are sealed or defined. The identifiers of features sealed 
or defined alike are grouped. If "Access" or "Responder" 
is absent from the first such group, "PRIVATE" or 
10 "INSTANCE", respectively, shall be considered present 
there. If "Access" or "Responder" is absent from any 
subsequent group, the keyword present in the previous 
group shall be considered present in the subsequent group. 
The interface is this. The "classFeatures" or 
15 "instanceFeatures" attribute comprises the features 
defined in groups with "CLASS" or "INSTANCE", 
respectively. The "isAbstract" attribute is "true" iff 
"ABSTRACT" is present. The "sealedClassFeatures" or 
"sealedlnstanceFeatures" attribute comprises the 
20 identifiers in groups with both "SEALED" and "CLASS" or 
"INSTANCE", respectively. The "superclasses" attribute 
comprises either the identifiers token "Superclasses" 
determines, if the latter is present, or the identifier of 
Class "Object" only, otherwise. The positions in the 
25 attribute of the classes decrease as their specifiers move 
from left to right. The "vocabulary" attribute is 
cleared. 

The interface is sealed iff "SEALED" is present. 
6.2.3 Feature 

30 Feature 

A feature definition obeys this rule: 

Feature ::=. Attribute | Operation 

APtyj^b^t:^ 

An attribute definition obeys this rule: 
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Attribute : : - [READONLY] Constraint 
[THROWS Identifiers] 
The attribute definition is this. The "constraint" 
attribute is the constraint given. The "exceptions" 
5 attribute comprises either the identifiers present, if 
"THROWS" is present, or no identifiers, otherwise. The 
"isPublic" attribute is "true" iff the key for the 
definition group that includes the attribute definition is 
"PUBLIC" or "CLASS". The "isSet" attribute is true iff 
10 "READONLY" is absent. 

A module's encoding, as defined above, of an 
attribute definition is sometimes called the signature of 
the attribute it defines. 

Qpgration 

15 An operation definition obeys this rule: 

Operation [UNPROTECTED] op ( 

ArgumentsAt tribute) 
[Constraint] [THROWS Identifiers] 
The operation definition is this. The "arguments" 
20 attribute is as given. The "exceptions" attribute 

comprises either the identifiers present, if "THROWS" is 
present, or no identifiers, otherwise. However, iff 
"UNPROTECTED" is present, the attribute comprises, 
additionally, the identifier for class "Reference 
25 Protected", which is thrown if the operation, which 
modifies the responder, is requested using a protected 
reference to the responder. The "isPublic" attribute is 
"true" iff the key for the definition group that includes 
the operation definition is "PUBLIC" or "CLASS" (see token 
30 "Interface- above) . The "result" attribute is either the 
constraint, if one is present, or a nil, otherwise. 

A module's encoding, as defined above, of an 
operation definition is sometimes called the signature of 
the operation the operation definition defines. 
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ArcTumentsAttribui;e 

An "arguments" attribute obeys these rules; 



Argument s At t r ibut e 
Arguments 
Argument Group 



- [Arguments] t . . . ] 

- ArgumentGroup [; Arguments] 
=> Identifiers : Constraint 



Zero or more arguments are described by their 
. constraints. Each such argument is denoted by an 
identifier. The identifiers of arguments constrained 
aliJce are grouped. If both one or more argument groups 
10 and the ellipsis (...) are present, the last group shall 
comprise just one argument, but shall be considered to 
comprise zero or more arguments. 

The -arguments" attribute is either a list of the 
constraints upon the zero or more described arguments, if 
15 the ellipsis (...) is absent, or a nil, otherwise. The 
positions, in the list, of the constraints upon the 
described arguments increase as their identifiers move 
from left to right. 



Constraint 
20 Constraint 
35 A constraint obeys these rules: 

Constraint [COPIED | PROTECTED | 

UNPROTECTED] ClassSpecif ier ["|" 
NIL] 



25 The constraint is this. The "classld" attribute is 

the identifier that token "ClassSpecif ier" determines. 
The -islnstance" attribute is "true" iff the exclamation 
mar]c ("!") is present within token "ClassSpecif ier" (see 
below) . The "isOptional" attribute is "true" iff "NIL" is 

30 present. The "of Class" attribute is a nil. The "passage" 
attribute is "byCopy" , "byProtectedRef " , 
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"byUnprotectedRef or "byRef" if -COPIED", "PROTECTED-, 
"UNPROTECTED", or none of these, respectively, is present. 

ClaasSpecifier 

A class specifier obeys these rules: 
ClassSpecifier ::« identifier [!] 

["[" ClassSpecif iers "] 
ClassSpecifiers ClassSpecif ier [, 
ClassSpecif iers] 

The identifier is that: of either a formal class 
10 parameter or a class, "C". In the latter case, iff the 
encoding, "E", of the interface of "C« is parameterized, 
there follow, between square brackets ("[" and "] ») , as 
many actual class parameters, each a class specifier, as 
"C" has formal class parameters. This particular use of 
15 "C" is as if each use of a formal class parameter within 
"E" were a use of the correspondingly positioned actual 
class parameter. 

^•2.5 Other Non -terminal a 

20 Characters constrained as is the text of an instance 

of class "Identifier". 



7 PREDEFINED f^ni^XJj.f^ 

The interfaces to the predefined classes are defined 
by a module which appears in full below and in fragments 
25 throughout this appendix. The Instruction Set's internal 
features do not appear in the module. 

This Section, i.e. Section 7, provided for reference 
purposes, duplicates material found elsewhere in this 
appendix. 

3 0 H2£a: The predefined interface definitions form a High 
Telescript module. To make this possible, 
certain Low Telescript identifiers are postfixed 
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with "_x" to avoid identifiers that are reserved 
words in High Telescript. 



10 



15 



20 



25 



10 



Telescript : 
Agent : 



15 



module = ( 

abstract interface (Process) = ( 
private 

go: unprotected op (ticket: copied 

Ticket) TicketStub 
throws Permit Viola ted, 

Statelmproper, TripException; 

send: unprotected op (tickets: 

copied List [Ticket] } 

TicketStub I Nil 
throws Fermi tViolated, 

Statelmproper, TripException; 

); 



30 
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Association: 



20 



25 



sealed interface [keyClass, valueClass: 
Class] (Object, Ordered) - ( 
public 

key: key CI as s ; 

value: valueClass; 
system 

initialize: unprotected op ( 
key: keyClass; 
value: valueClass); 

) ; 



Attribute: sealed interface (Feature) ( 
public 

constraint : Constraint ; 

isSet; Boolean; 



55 



351 



BNSDOCID: <EP 063471 9A2_I_> 



EP 0 634 719 A2 



10 



system 

initialize: unprotected op ( 
constraint : Constraint | Nil ; 
isSet/ isPublic: Boolean j Nil; 
exceptions: Set 



[Identifier!] I Nil) 



); 



IS 



20 



25 



Authenticator: abstract interface = (); 



10 0; 



Bit: sealed interface (Primitive , Ordered) » 



BitString: sealed interface (ConstrainedList 
[Bit] , Executed) - ( 
public 

constraint: sealed; 



30 



35 



15 



system 



initialize: unprotected op 
(segments: Object ... 
/* Bit Iprotected BitStringl */) ; 



); 



20 Boolean: sealed interface (Primitive, Ordered) 

40 ( public 

and, or: op (boolean; Boolean) 

Boolean; 



46 



25 



not: op 0 Boolean; 



); 



so 



CalendarTime : interface « ( 

public 
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day, dst, hour, minute, month, 
second, year, zone: 
Integer I Nil; 

dayOfWeek, dayOfYear: readonly 
Integer I Nil; 

globalize, localize : unprotected 



Boolean; 



10 



normalize: unprotected op () 



); 



15 



Cased: abstract interface () » { 
public 

isLower, isUpper: abstract 
readonly Boolean; 



makeLower, makeUpper: abstract op 
0 copied Cased; 



); 



Character: 



sealed interface (Primitive, Cased, 
Ordered) = (); 



20 Citation: interface (Object, Ordered) - ( 

public 

author: Telename |Nil ; 



Integer I Nil; 



ma j orEdition, minorEdi tion : 



25 



title: Identifier! ; 
system 

initialize: unprotected op ( 
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Citation; 

10 



title: Identifier! ; 
author; Telename |Nil; 
ma j or Edi t ion , minorEdi t ion : 
Integer I Nil) ; 

)/ 

Cited: abstract interface 0 « ( 
public 

citation: readonly protected 



system 

initialize: unprotected op ( 
title: Identifier!; 
majorEdition, minorEdi t ion; 

Integer) ; 

15 ) ; 



Class: sealed interface (Object, 
Cited, Interchanged) « ( 
public 

convert: sealed op (source :- 
protected Object) 
copied Object 

35 throws ConversionUnavailable; 

islnstance: sealed op (instance__x: 
protected Object) Boolean; 



25 



50 
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isMember: sealed op (member: 
protected Object) Boolean; 

isSubclass: sealed op (subclass: 
Class) Boolean; 

new: sealed op (parameters: Object 
. . . ) Object 
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10 



throws ClassAbstract, Exception, 
Ob j ectUninit ial ized ; 

system 

initialize: unprotected op () 
throws FeatureUnavailable; 



) ; 



15 



ClassDef inition : 



sealed interface - ( 
public 

implementation : 



10 Implementation | Nil ; 



20 



interface_x: Interface; 



25 



30 



Integer; 



15 



majorEdition, minorEdition: 



makeClassea: op (definitions: 
protected ClassDef inition 
Lexicon [Class] 

throws ClassException; 



35 



40 
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20 



minorEdition: Integer; 



25 



Implementation I Nil) ; 

); 



title: Identifiers- 
system 

initialize: unprotected op (title; 
Identifier! ; 
majorEdition, 

interf ace_x : Interface ; 
implementation : 



50 



ClassException: abstract interface 
(ProgrammingException) = (); 
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ClassSealed : interface (ClassException) 

= 0 ; 

ClassUndef ined : interface 
(ClassException) = ( ) ; 

Feat ureRedef ined: 

interface (ClassException) = (); 
FeatureSealed : interface 

(ClassException) = (); 
FeatureUndef ined : 
10 interface (ClassException) = (); 

MixinDisallowed : 

interface (ClassException) = {) ; 
Superclasseslnvalid: 

interface (ClassException) = () ; 

15 Collection; interface [itemClass: Class] «( 

public 

clear: unprotected op () ; 

examine: op (item: protected 
itemClass) itemClass [Nil ; 

exclude: unprotected op (item: 
protected itemClass) 
itemClass | Nil 

include: unprotected op (item: 

throws Itemlnvalid; 
length: readonly Integer; 

stream: op () copied Stream 
[itemClass] ; 

system 

initialize: unprotected op (items: 
itemClass . . . ) 



20 

35 



40 

ItemClass) 

25 
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so 30 
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throws Itemlnvalid; 



10 



15 



20 



25 



30 



35 



40 



) ; 



10 



15 



Collection abstract interface 
(ProgrammingException) = () ; 
5 Exception: ItemDuplicated : 

interface (CollectionException) -() ; 
Itemlnvalid: 

interface (CollectionException) =() ; 
KeyDuplicated: 

interface (CollectionException) ={); 
Keylnvalid: 

interface (CollectionException) =() : 
Ob j ectsUnpaired : 

interface (CollectionException) =(): 
Positionlnvalid : 

interface (CollectionException) =() : 
StackDepleted : 

interface (CollectionException) = 0 ; 



20 



25 



Constrained; 



Constraint I Nil) 



abstract interface 0 = ( 
public 

constraint : 
readonly protected Constraints- 
system 

initialize: unprotected op ( 
constraint : copied 



) ; 



45 



50 



Constrained 
Dictioncary: 



30 



interface [keyClass, valueClass: Class] 
(Dictionary [keyClass, valueClass] , 

Constrained) = ( 

system 

initialize: unprotected op ( 

constraint: copied Constraint; 
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ConstrainedList : 



ConstrainedSet ; 



keysAndValues : Object ... 
/* key: keyClass; value: 
valueClass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



); 



interface [itemClass: Class] (List 
[itemClass] , Constrained) = { 
system 

initialize: unprotected op { 
constraint: copied Constraint; 
items: itemClass . . . ) 
throws Itemlnvalid; 

); 

interface [itemClass: Class] 

(Set [itemClass] , Constrained) = ( 
system 

initialize: unprotected op ( 

constraint: copied Constraint; 
items : itemClass . . . ) 
throws ItemDuplicated, 
Itemlnvalid; 

) ; 



40 



45 
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Constraint: interface « ( 
public 

classid: Identifier!; 

islnstance, isOptional: Boolean; 
of Class: readonly Class] Nil; 
passage : Identifier ! 
throws Passage Invalid; 
system 

initialize: unprotected op ( 
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Identifier! |Nil; 
Boolean I Nil) 



Contact ; 



Contacted: 



classid, passage: 
isOptional, islnstance: 
throws Passagelnvalid; 



); 



interface = ( 
public 

subject: Process j Nil; 
subjectClass: rea.donly protected 

Citation I Nil / 
subjectName: readonly protected 

Telename|Nil; 
subjectNotes: Object |Nil; 

system 

initialize: unprotected op ( 
subject: Process I Nil; 
subjectNotes: ObjectjNil); 

); 

abstract interface 0 = ( 
private 

contacts: readonly Set [Contact]; 

); 



Dictionary: interface [keyClass, valueClass: Class] 
(Set [Association [keyClass, 

valueClass) 1 ) = ( 
public 

add: unprotected op (key: keyClass; 

value: valueClass) 
throws Keylnvalid; 
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drop: unprotected op (key: protected 
keyClass) valueClass 



find : op (value : protected 
valueClass ) keyClass | Nil ; 

get: op (key: protected keyClass) 

valueClass 
throws Keylnyalid; 

rekey: unprotected op ( 

currentKey: protected keyClass; 

newKey: keyClass) 
throws Keylnvalid; 

set : unprotected op ( 

key: protected keyClass; 
value: valueClass) 



transpose: unprotected op (keyl, 

key2: protected keyClass) 
throws keylnvalid; 
system 

initialize: unprotected op 
(keysAndValues : Object ... 
/♦ key: keyClass; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 



5 



throws Keylnvalid; 



30 



throws Keylnvalid; 



45 



ObjectsUnpaired; 



); 



Exception: 



abstract interface (Object , Unchanged) = 
(public 

throw_x: sealed op (); 

); 



so 
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Executed: abstract interface () = ( 
public 

catch_x: sealed op (exception: 

Class) Exception | Nil 
throws Exception; 

do_x, loop_x: sealed op () 
throws Exception; 

either: sealed op (false_x: 
Executed; precondition: Boolean) 
throws Exception; 

if_x: sealed op (precondition: 
Boolean) 

throws Exception; 

repeat_x: sealed op (repetitions 
Integer) 

throws Exception; 

while^x: sealed op (precondition; 
Executed) 

throws Exception, Resultlnvalid, 
ResultMissing; 

); 

Execution abstract interface (KernelException) = 
Exception: 

Argument Invalid : 

interface (ExecutionException) o { ) ; 
ArgumentMissing : 

interface (ExecutionException) = () ; 
At tributeReadOnly : interface 

(ExecutionException) = () ; 



361 



EP0634719A2 



10 



ClassUnavailable : 

interface (ExecutionException) - () ; 
Escalationlnvalid : 

interface (ExecutionException) » () ; 
5 FeatureUnavailcdDle : 

interface (ExecutionException) » () ; 
InternalException : 

interface (ExecutionException) = () ; 
IS Property Undefined: 

10 interface (ExecutionException) « (); 

Ref erenceProtected : 

interface (ExecutionException) » (); 
^ ReferenceVoid: 

interface (ExecutionException) - (); 
15 ResponderMissing : 

interface (ExecutionException) - (); 
Result Invalid: 

interface (ExecutionException) - (); 
ResultMissing: 

20 interface (ExecutionException) » () ; 

Va r i ab 1 eUnde f ined : 

interface (ExecutionException) » () ; 

35 Feature: abstract- interface « ( 

public 

25 exceptions: Set [Identifier!]; 

^ isPublic: Boolean; 

system 

initialize: unprotected op ( 
isPublic : Boolean I Nil? 
^ exceptions: Set 

[Identifier!] jNil) ; 

) ; 



25 



30 
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Hashed: abstract interface 0 - ( 
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^0 5 {); 



15 



20 



35 



public 

hash: abstract readonly Integer; 

); 

Identifier: sealed interface (Primitive, Ordered) 



Implementation; sealed interface - ( 

public 



10 



classMethods, fromMethods, 
instanceMethods, setMethods, 
toMethods: Lexicon [Method!; 

properties: List [Identifier!]; 

superclasses: List 
25 fidentifieri] |Nil; - 

vocabulary : Lexicon 
[Citation) |Nil; 
^ system 

initialize: unprotected op ( 
superclasses: List 
[Identifier!] |Nil; 
vocabulary: Lexicon 
[Citation] |Nil; 
properties: List 
^ [Identifier!] |Nil; 

instanceMethods, setMethods, 

classMethods, 
fromMethods, toMethods: Lexicon 
46 [Method] I Nil] ; 

); 



20 



25 



SO 30 



Integer: sealed interface (Number) 
public 



( 
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modulus, quotient: op (divisor 

Integer) Integer 
throws DivisionByZero; 

); 

5 Interchanged: abstract interface (Unchanged) » { 

pxiblic 

digest: abstract readonly 
protected Object jNil; 

15 ) ; 

10 Interface: sealed interface = ( 

public 



20 



classFeatures , instanceFeatures 
Lexicon ^ [Feature] ; 

25 isAbstract: Boolean; 

sealedClassFeatures , 

sealedlnstanceFeatures : 
Set [Identifier!] ; 

superclasses: List [Identifier!] 



30 



35 



vocabulary: Lexicon [Citation] ; 
2^ system 

initialize: unprotected op ( 
superclasses : List 
[Identifier!] |Nil; 
vocabulary: Lexicon 
2^ [Citation] |Nil; 

instanceFeatures : 

Lexicon [Feature] |Nil; 
sealedlnstanceFeatures : 
» Set [Identifier!] |Nil; 



40 
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15 



20 



26 



30 



40 



classFeatures : Lexicon 
[Feature] |Nil/ 
sealedClassFeatures : 

Set [Identifier!] |Nil; 
^ isAbstract: Boolean | Nil ) ; 

); 

Kernel 

Exception: abstract interface 

(ProgrammingException) « () ; 

^0 ClassAbstract : interface 

(KernelException) = () ; 



15 



ConversionUnavailable : 

interface (KernelException) = () ; 

CopyUnava i 1 abl e : 

interface (KernelException) = () ; 

LoopMissing: interface (KernelException) 
= 0; 

35 MarkMissing: interface (KernelException) 

= (); 



2^ ObjectUninitialized: 



25 

50 
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interface (KernelException) « (); 



Pas sage I n va 1 i d : 

48 interface (KernelException) =. () ; 



SelectorDuplicated: 

interface (KernelException) = (); 

Lexicon: interface (valueClass: Class) 
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10 



(ConstrainedDictionary [Identifier, 

valueClass] ) = ( 
public 

constraint: sealed; 
system 

initialize: unprotected op 

(keysAndValues: Object ... 
/* key: Identifier!; value: 
IS valueClass */) 

throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



10 



20 



15 

25 



List: interface [itemClass: Class] 

(Collection [itemClass] , Ordered) 
- ( 
public 

add: unprotected op (position: 
Integer; item: itemClass) throws 
30 Itemlnvalid, Positionlnvalid; 

drop: unprotected op (position: 
Integer) itemClass 
35 throws Positionlnvalid; 

find: op ( 

initialPosition: Integer; 
item: protected itemClass) 
Integer I Nil 
throws Positionlnvalid; 

46 

get: op (position: Integer) 
itemClass 

throws Positionlnvalid; 

50 



40 
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reposition: unprotected op 

(currentPosition, newPosition 
Integer) 

throws Positionlnvalid; 



5 



set: unprotected op (position: 
Integer; item: itemClass) throws 
Itemlnvalid, Positionlnvalid; 



transpose; unprotected op 
(positionl, position2: Integer) 
throws Positionlnvalid; 
system 

initialize: unprotected op (items 
itemClass . . . ) ; 

); 

Wark: sealed interface (Primitive) = (); 

Means: abstract interface » (); 

MeetingException: abstract interface (Exception) - () ; 

MeetingDenied : 

interface (MeetingException) =(); 
° MeetingDuplicated: 

interface (MeetingException) « (); 
Meetinglnvalid: 

interface (MeetingException) = {); 
Pet itionExpired : 
5 interface (MeetingException) - (); 

MeetingPlace: abstract interface (Place) - ( 

public 
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meet: unprotected op (petition 
copied Petition) Contact 

throws MeetingException, 
ProcessNot Current , 
Statelmproper; 

part: unprotected op (contact: 
Contact) 



throws Meetinglnvalid, 
ProcessNot Current , 
Statelmproper; 
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20 



partAll: unprotected op () 
throws ProcessNotCurrent, 
Statelmproper; 



); 



15 Method: sealed interface « ( 

public 

procedure : Procedure ; 



variables: List [Identifier!]; 
system 

initialize: unprotected op ( 
procedure : Procedure | Nil ; 
variables: List 

40 [Identifier 1 ] |Nil) ; 

) ; 



25 Miscellaneous abstract interface 

(ProgrammingException) » () ; 
Exception: 

Patternlnvalid: interface 
so (MiscellaneousException) = {); 
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0 ; 



Seedlnvalid: 

interface (MiscellaneousException) 



10 



IS Telename; 



Modifier: sealed interface (Primitive) = {); 



Named: abstract interface () = ( 
public 

name: sealed readonly protected 

); 



20 
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Nil: 
Number : 



- ( 



Numbers- 



sealed interface (Primitive) » () ; 
abstract interface (Primitive, Ordered) 
public 

abs, negate; abstract op () 



add, multiply: abstract op 
(number: Number) Number / 

ceiling, floor, round, truncate; 

abstract op () Integers- 
divide: abstract op (divisor: 

Numbe r ) Numbe r 
throws DivisionByZero; 



subtract: abstract op (subtrahend: 
Number) Number; 



) ; 



Object: abstract interface (Referenced) » ( 
public 
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(); 



class: sealed readonly Class; 
copy: sealed op {) copied Object 

throws CopyUnavailable; 

isEqual: op (object: protected 



5 Object) Boolean; 



select: sealed op (associations: 
Object ... 



/♦ protected Object; Executed 
20 */) 

throws Exception, 

SelectorDuplicated; 



size: sealed readonly Integer; 
system 

finalize / initialize: unprotected 

op (); 

); 

Octet: sealed interface (Primitive, Ordered) - 



20 



OctetString: sealed interface (ConstrainedList 

[Octet] , Executed) « ( 
public 

constraint : sealed ; 
45 system 

initialize: unprotected op 
(segments: Object 
/* Octet I protected OctetString! 
V); 



25 



50 



55 



370 



BNSDOCID: <EP 0634719A2J_> 



EP 0 634 719 A2 



15 



30 



[Constraint] |Nili 



Operation: sealed interface (Feature) = ( 
public 

5 

arguments: List [Constraint] {Nil; 

result: Constraint I Nil; 
10 5 system 

initialize : unprotected op ( 
arguments: List 

result: Constraint | Nil ; 
isPublic: Boolean I Nil; 
exceptions : Set 

[Identifier!] iNil) ; 

20 

); 

Ordered: abstract interface 0 = ( 
25 15 public 

isAfter, isBefore: abstract op 
(object: protected Ordered) 
Boolean; 
max, min: op (object: Ordered) 
20 Ordered; 

); 

35 

Package: interface (ConstrainedSet [Class]/ 
Cited, Interchanged) » ( 
public 

constraint : sealed; 
system 

initialize: unprotected op ( 
title: Identifier!; 
ma j orEdi t ion , minorEdi t ion : 
Integer; 
items: Class . . . ) 
» throws ItemDuplicated, 

ProcessNotPeer; 



40 25 

45 
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); 

Pattern: interface (Object, Ordered) = ( 
public 

find: op (string: protected 

String*; position: IntegerjNil) 
List [Integer] |Nil 
throws Positionlnvalid; 
substitute: op ( 

repetitions : Integer/ 
string: unprotected String!; 
replacement; protected String!) 
20 Integer; 

system 

initialize: unprotected op (text; 

copied String!) 
throws Patternlnvalid; 

); 
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Permit: interface (Object, Ordered) = ( 
public 

age, authenticity, charges, 

extent, priority: Integer,' Nil; 

canCharge, canCreate, canDeny, 
canGo , canGrant , canRest ar t , 
canSend: Boolean; 

intersect: op (permit: Permit) 
Permit; 

system 

initialize: unprotected op (age, 
charges, extent: Integer 1 Nil ) ; 

Petition: interface = ( 
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public 

agentClaas: Citation! Nil; 
agentName : Telename | Nil / 

maximumWai t : Integer j Nil ; 
5 system 

initialize: unprotected op ( 
agentName: Telename j Nil / 
agentClaas : Citation | Nil; 
maximumWai t : Integer | Nil ) ; 

10 ); 



Petitioned: abstract interface () - ( 
system 

meeting: unprotected op ( 
25 contact: Contact; petition: 

protected Petition) 
throws MeetingDenied; 



20 



25 

46 



so 



parting: unprotected op (contact: 
Contact) ; 



Place: abstract interface (Process, Unmoved) 



public 

40 address: sealed readonly protected 

Teleaddress; 



publicClasses: sealed readonly Set 
[Cited] ; 

terminate : sealed unprotected op ( 
occupant: protected Telename) 
Boolean 
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throws ProcessNotCurrent , 

ProcessNotPeer, St ate Improper ; 

system 

entering: unprotected op ( 

contact ; Contact ; 

permit: protected Permit; 

ticket: protected Ticket | Nil) 
throws OccupancyDenied; 



exiting: unprotected op ( 
^0 contact: Contact; 

permit: protected Permit; 
20 ticket: protected Ticket (Nil) ; 

.) ; 



25 15 



30 



Primitive: abstract interface (Object, Executed, 
Unchanged) » ( 
system 

initialize: unprotected op () 
throws FeatureUnavailcUble; 

); 



20 Primitive abstract interface 

35 (ProgrammingException) - (); 

Exception: 

DivisionByZero : interface 

(PrimitiveException) « {) ; 

Procedure: sealed interface (Primitive) - (); 



25 



Process: abstract interface (Object, Named, 
Uncopied) « ( 
public 

brand: sealed readonly protected 
50 ^0 Object 

throws ProcessNotPeer; 
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localPermit: sealed copied Permit 
throws FeatureUnavailable, 
PermitViolated; 

nativePermit: sealed copied Permit 
throws FeatureUnavailable, 
PermitViolated; 

permit: sealed readonly copied 

throws ProcessNotPeer; 

regionalPermit : sealed copied 

throws FeatureUnavailable, 
PermitViolated; 

private 

age: sealed readonly Integer; 
charges: sealed readonly Integer; 
contacts: sealed readonly 

priority: sealed Integer [Nil; 

privateClasses: sealed readonly 
Set [Cited] ; 

public 

charge: sealed op (charges: 

Integer) 
throws Permit Inadequate, 

PermitViolated; 
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restrict_x: sealed op { 
procedure : Procedure ; 
pemit: protected Permit) 
throws Exception, PermitViolated, 
5 ProcessNotCurrent ; 

sponsor_x: sealed op ( 
procedure : Procedure ; 
permit: protected Permit) 
throws Exception, PermitViolated, 
10 ProcessNotCurrent; 

20 - wait: unprotected op (seconds: 

Integer) ; 



10 



IS 
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system 

initialize: op ( 

nativePermit : copied Permit; 
privateClaases : Set 
[Cited] I Nil) 
throws PermitViolated; 



live: abstract unprotected op 
^ 2° (cause: Exception I Nil) 

throws Exception; 



40 



25 ) ; 

45 



restricted: op (permit: 

Identifier; isRelocated: 
Boolean) PermitReduced j Nil ; 



50 
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Process- abstract interface 

(ProgrammingException) = () ; 

Exception: 

Permitlnadequate : interface 
(ProcessException) - (); 
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ConditionUnavailable : 

interface (ProcessException) = () ; 

Condi t ionUnde f ined : 

interface (ProcessException) » {) ; 

PermitExhausted : 

interface (ProcessException) = () ; 

Permi tViolated : 

interface (ProcessException) = () ; 

ProcessNotCurrent : 

interface (ProcessException) « (); 

ProcessNotPeer : 

interface (ProcessException) = () ; 

ResourceUnavailable : 

interface (ProcessException) = () ; 

State Improper : 

interface (ProcessException) = () 

Programming abstract interface (Exception) » () ; 
Exception: 

Qualified sealed interface (Identifier) = () ; 
Identifier: 

RandomStream: interface (Stream [Integer]) = ( 

system 

initialize: unprotected op (seed: 

Integer) 
throws Seedlnvalid; 

) ; 
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Real: sealed interface (Number) = () ; 

Referenced: abstract interface 0 = ( 
public 

discard: sealed op () ; 

^ isProtected: sealed readonly 

Boolean; 

isSame: sealed op (reference: 

protected Referenced) Boolean; 

protect: sealed op () protected 
" Referenced; 

refjK: sealed unprotected op () ; 

); 



Resource: interface « ( 
30 public 

condition: Identifier! 
throws ConditionUnavailable; 



40 



so 



55 



conditions: readonly protected Set 
[Identifier!] ; 



use: sealed unprotected op { 
procedure: Procedure; 
exclusive: Boolean] Nil; 
maximumWait : Integer \ Nil ; 
45 conditions: copied Set 

[Identifier!] |Nil) Boolean 



tlirows Condi tionUnde fined. 

Exception, ResourceUnavailable; 

system 
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initialize; unprotected op { 
5 condition: Identif ier 1 iNil ; 

conditions: copied Set 

[Identifier!] |Nil) throws 
^ Condi t i onUnde f ined ; 

10 ); , 



15 



10 



40 

25 

45 
50 



Selector: sealed interface (Primitive) 



(); 



Set: interface [itemClass: Class] 

(Collection [itemClass] , Verified) 

( 

20 public 

difference, intersection, union: 
unprotected op (set: protected Set 
[itemClass] ) ; 

^5 system 

initialize: unprotected op (items: 
itemClass . . . ) 

30 throws ItemDuplicated, Iteralnvalid; 



2 0 Stac]c: 



); 



interface [itemClass: Class] (List 



^ [itemClass] ) = ( 

public 



pop: unprotected op () itemClass 
throws StaclcDepleted; 

push: unprotected op (item: 
itemClass) ; 

pushltems: unprotected op ( 
items: protected List 
[itemClass] ) ; 
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roll; unprotected op (shifts, 

items: Integer) 
throws Argumentlnvalid, 
StackDepleted; 

swap; unprotected op () 
throws StackDepleted; 



) ; 



stream: abstract interface [itemClass: Class] 
( 

10 public 

current: abstract readonly 
itemClass I Nil ; 

isDone: abstract Boolean; 

next: abstract readonly 
^5 itemClass I Nil 



throws ReferenceProtected; 



30 ] ; 



String: sealed interface 

(ConstrainedList [Character] , Cased, 

Executed) » ( 
public 

constraint : sealed; 



substring: op (initialPosition, 
beyondFinal Posit ion : Integer) 
copied String 

« throws Positionlnvalid; 

system 

initialize: unprotected op 
(segments: Object ... 
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/* Character I protected String! 
*/): 

); 



Teleaddress: interface = ( 
10 5 public 



location: String! |Nil; 
provider: OctetString! ; 



routingAdvice ; List 
[OctetString!]; 
system 

initialize: unprotected op ( 
provider: OctetString! | Nil; 
location: String! |Nil) ; 

25 ) . 

15 Telename: interface « { 

public 



authority: OctetString!; 



identity: OctetString! {Nil; 
35 system 

initialize: unprotected op { 
authority, identity: 
OctetString! |Nil) ; 

); 



Telenumber: interface = ( 
4g public 



50 



country, telephone: string!; 

extension: String! jNil; 
system 
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initialize: unprotected op ( 
countryAndTelephone : String ! ; 
extension: Stringl jNil) ; 



10 5 Ticket: interface (TicketStub) » ( 

public 

desiredWait, maximumWait : 
Integer I Nil; 
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destinationAddress ; 
10 Teleaddress|Nil; 
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30 



20 



); 



destinationClass: Citation | Nil; 

destinationName: TelenamejNil; 

destinationPermit : Permit [Nil; 
system 

initialize: unprotected op ( 

destinationName: Telename | Nil; 
destinationAddress : 
Teleaddress | Nil ; 
destinationClass : Citation | Nil ; 
maximumWait: Integer |Nil; 
way: Way | Nil; 

travelNotes: Object |Nil) ; . 



TicketStub: interface = { 
25 public 

45 



travelNotes: Object (Nil; 

way: Way | Nil; 
system 

initialize: unprotected op ( 
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way: Way j Nil; 
travelNotes: Object|Nil); 

) ; 

Time: interface (Object, Ordered, Unchanged) » 

( 

public 

adjust: op (seconds: Integer) Time; 
interval: op (sxibtrahend: Time) Integer; 
); 



10 TripException: abstract interface (Exception) « { 
2Q pxiblic 

ticketStub: sealed TicketStub; 
system 

initialize: unprotected op 
15 (ticketStub: TicketStub); 

); 



^ DestinationUnavailable : 

interface (TripException) = () ; 

Destinat ionUnknown : 
^ 20 interface (TripException) = {); 

OccupancyDenied : 

interface (TripException) = () ; 

TicketExpired: interface (TripException) 
- (); 

45 

25 WayUnavailable: interface 

(TripException) • {); 

^ Unchanged: abstract interface ()«(); 
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Unexpected: interface (ExecutionException) = ( 
Exception: public 

exception: readonly Exception; 
system 

^ initialize: unprotected op ( 

exception: Exception) ; 
); 

Unmoved: abstract interface () « () ; 

Verified: abstract interface 0 = ( 
10 public 

verify: abstract op () Boolean; 

) ; 



. Way: interface « ( 
25 public 



15 



authent icator : Authenticator | Nil ; 
means : Means | Nil ; 



name: Telename |Nil; 
system 

35 initialize; unprotected op { 

name: Telename [Nil; 
means: Means | Nil; 
authenticator: 
Authenticator I Nil) ; 

); 

) /* Telescript */ 



8 PREDEFINED nPi^Pff 

The diagram below shows the part of the class graph 
involving the predefined classes. The immediate 
subclasses of a class lie indented just below it. Classes 
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which are underlined are abstract, 

enclose mix-ins. 
QM^qt (Referenced) 

Association ( Ordered ) 
Autpj^entjc^tQ?: 
Calendar Time 
Citation (Ordered) 
Class (Citgd & Interehanq^r^^ 
Class Definition 
Collection 

List (Ordered) 

• Constrained List ( Constra;n*>y j^) 

• •Bit String (Executed) 

• • Octet String ( Executed ) 

• • String (£ased & Execute^ )^ 

• Stack 
Set ( Verified ) 

• Constrained Set ( Constrained ) 

• • Package ( Cited & Interchangpd ) 

• Dictionary 

• • Constrained Dictionary ( Constrainec^ ) 

• • • Lexicon 
Constraint 
Contact 

PXception ( Unchang ed) 
M^^ti^q Except; if7n 
Programming R xceotion 

• Class Ryr^p^ir^n 
Collect:ior^ E xception 
Keyne; E^^cep^ton 

• Execute Except: 

• • Unexpected Exception 
Mi3cellanRi7n« Exception 
Pyiniitive Excgphi^iTi 
Process Eyr -eption 



Trip Exg^p^inp 
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Feature 

• Attribute 

• Operation 
Implementation 
Interface 
Means 

Method 

Pattern ( Ordered ) 
Permit ( Ordered ) 
Petition 

Primit;ivQ (Ex^Siitfid & Unchanogd ) 
Bit ( Ordered ) 
Boolean (Ordered) 
Character ( Cased & Ordered ) 
Identifier ( Ordered ) 

• Qualified Identifier 
Mark 

Modifier 
Nil 

Number ( Ordered ) 

• Integer 

• Real 
Octet ( Ordered ) 
Procedure 
Selector 

PrpcQss ( Named ) 



35 



Agent 

Place ( Unmoved ) 
• Meeting Plac^ 
Resource 
Streat^ 

• Random Stream 
Teleaddress 
Telename 
Telenumber 
Ticket Stub 
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• • Ticket 

• Time (Ordg^gd & Unchanged ) 
5 • Way 

CasM 
5 £it£d 

Constrained 

10 

Contacted 

Hashed 
15 10 Named 

Petitioned 

20 

Unchanged 
15 • Interchang^ta 
Unmoved 

2« Verified 
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APPENDIX B 

Copyright ® General Magic, Inc. 1991, 1992, 1993. All 

Rights Reserved 

The following Table of Contents is to assist the 

5 reader in understanding the organization of and locating 
information within this appendix. 

IS Table of Contents 

1 INTRODUCTION 
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10 1.2 References 

2 ENCODING CONCEPTS 

2.1 Teleparcel 

2.2 Object Encoding 
25 2.2.1 Forms 

15 2.2.2 Rules 

2.2.3 Palettes 

2.2.4 Encoding Classes 

2.2.5 Encoding Attributes 

2 . 3 Attribute Encoding 
20 2.3.1 Forms 

35 2.3.2 Rules 

2 . 4 Reference Encoding 

2.4.1 Forms 

2.4.2 Rules 

^ 25 3 ENCODING SPECIFICATIONS 

3 . 1 Conventions 

3 . 2 Teleparcel 

45 3 .3 Object Encoding 

3.3.1 Executed Object 

30 3.3.2 Predefined Object 

3.3.3 User-defined Object 
^ 3.3.4 Protected Object 

3.3.5 Palette 
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3 . 4 Attribute Encoding 

3.4.1 Boolean 

3.4.2 Dial String 

3.4.3 Integer 
5 3.4.4 Item 

3.4.5 List 

3.4.6 Octet String 

3.4.7 Stack 

3.4.8 String 
10 3,5 Reference Encoding 

3.5.1 General Reference 
3.5-2 Voided Reference 

3.5.3 Interchange Reference 

3.5-4 Class Reference 

15 3.5.5 Procedure Reference 

4 ENCODING CLASSES AND ATRRIBUTES 

25 4,1 Conventions 

4.2 Encoding Group 

4.2.1 Catch Frame 

20 4.2.2 Collection Stream 

4.2.3 Dial String 

4.2.4 Frame 

4.2.5 Go Frame 

35 4.2.6 Predefined Frame 

25 4.2.7 Procedure Frame 

4.2.8 Repeat Frame 

4.2.9 Restrict Frame 

4.2.10 Send Frame 

4.2.11 Use Frame 
30 4.2.12 User-defined Frame 

4.2.13 While Frame 

4.3 Encoding Attributes 

4.3.1 Agent 

4.3.2 Catch Frame 
35 4.3.3 Collection 

4.3.4 Collection Stream 
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4.3.5 


Dictionary 




4.3.6 


List 




4.3,7 


Pattern 


5 


4.3.8 


Procedure Frame 




5 4.3.9 


Random Stream 




4.3.10 


Repeat Frame 


10 


4.3.11 


Restrict Frame 




4.3.12 


Send Frame 




4 .3 . 13 


Stack 
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Time 


4 . 3 . 15 


Use Frame 
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User-defined Frame 




4 . 3 . 17 


While Frame 
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Conventions 
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Language Classes 


25 
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Agent 
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Association 
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Attribute 


30 
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3.2.4 


Calendar Time 


5.2.5 


Citation 
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Class 
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Class Definition 


35 
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Collection 






Constrained Dictionary 
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Constrained List 
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Constrained Set 
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Constraint 
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Contact 




30 5.2.14 


Dictionary 


45 


5.2.15 


Implementation 
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5.2.17 
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Method 
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Mix-in 



55 



390 

BNSDOCID: <EP_0634719A2J_> 



EP 0 634 719 A2 



5.2.21 Operation 
^ 5.2.22 Package 

5.2.23 Pattern 

5.2.24 Permit 

5 5.2.25 Petition 
10 5.2.26 Random Stream 

5.2.27 Resource 

5.2.28 Set 

5.2.29 Stack 
10 5.2.3 0 Teleaddress 

5.2.31 Telename 

5.2.32 Telenumber 

5.2.33 Ticket 

5.2.34 Ticket Stub 
15 5.2.35 Time 

5.2.36 Trip Exception 

5-2.37 Unexpected Exception 

5.2,38 Way 
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25 5.3.6 Send Frame 
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5.3.8 User-defined Frame 

5.3.9 While Frame 



IS 



20 



25 



30 



40 



1^ INTRODTTCTTOM 

45 3 0 Section 1 of Appendix A of this disclosure introduces 

the major elements of the present invention and that 
discussion is incorporated herein by reference. The 
conventions described in Section 1.4.3 of Appendix A are 
followed in this appendix as well. 
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1 . 1 Organization 



This appendix is divided into three sections. 
Section l is this introduction- Section 2 introduces the 
Encoding Rules' major concepts. Section 3 defines the 
5 predefined classes and attributes -- beyond those in the 
Instruction Set that are used in encoding. 

This appendix relies upon these other documents: 
[10646] 

10 IqfQrm»t;iop technoXoav -- Universal rn d ed ChaT-ani-f>i- 

S£t (UCS) , ISO/IEC DIS 10646, International Organization 
for Standardization and International Electrotechnical 
Commission, 1990. 

[Telescript] 
15 Appendix A of this disclosure, 

[Unicode] 

Thg VniCQde standard: Worldwide C haracter Enrodi^g . 
Volume 1, Version l.O, The Unicode Consortium, 
Addison-Wesley, 1991. 

20 a ENCODING COJ^CK^Jff 

Teleparcels are conceived in this section of this 
appendix. Subsections are devoted to teleparcels and to 
object, attribute, and reference encodings. 

2ulX T^lep^ypQl 
25 A "teleparcel" encodes an object, which is the 

teleparcel's "subject", the subject's components, and all 
of their components, recursively. The class of the 
subject or any component can be either predefined or 
user -defined. 

30 Nbtfi: A teleparcel is a Telescript object in its 




canonical form. 
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Nots: A teleparcel is the means by which an object is 
transported between two Engines. A source 
Engine transforms an object into a teleparcel 
and transports it to a destination Engine. The 
latter transforms the teleparcel into an object, 
thereby producing at the destination the same 
object consumed at the source. 

Note: A teleparcel 's subject is typically, although 

not exclusively, an agent. In such cases, the 
teleparcel encompasses the agent and all the 
objects the agent owns, including those that 
make up the agent's current execution state. 

1^ Object Encodii^g 

An "object encoding" encodes an object and a 
reference to the object. 

2i2t^ Form? 

An object encoding assumes one of these forms: 

An "executed object encoding" encodes an executed 
object. 



A "predefined object encoding" encodes an unexecuted 
object whose class is predefined. 

U?er-d^gtnec1 

A "user "defined object encoding" encodes an object 
whose class is user-defined, 

Proteet^eg^ 

A "protected object encoding" encodes an arbitrary 
object. 
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Encoding an object also encodes a reference to the 
object. The reference is protected iff either the object 
xs unchanged or the object encoding's fom. is protected. 

Rules 

5 The form of the object encoding for an object, and a 

reference, shall be selected in accordance with the 
following rules, applied in the order given- 

1. A protected object encoding shall be selected if the 
reference is protected and the object is not 

10 unchanged. 

2. An executed object encoding shall be selected if the 
object is executed. 

3. A predefined object encoding shall be selected if the 
class of the object is predefined. 

15 4. A user-defined object encoding shall be selected 
(otherwise) . 

^^^•3 Paletr..»a 

An object encoding can draw upon an "encoding 
palette", which is a set of predefined attributes and 
20 rules governing their inclusion in an object encoding 

A predefined or user-defined object encoding draws 
upon a "primary- palette determined by the predefined 
class Of Which the encoded object, "0", is an example. An 
Object xs an "example" of a predefined class iff the 

orer^ "." -P^--t-t-n member of that class but of no 
predefined subclass thereof. 

A user-defined object encoding also draws upon a 
secondary, palette, which is defined in section 5.2.20 of 

30 While'''"''"' " --"--ed. or named 

30 While an instance of the predefined class of which "0- is 
an example is not cited, constrained, or named. 

either"" r**"'''"^ attribute in a palette is designated 
either mandatory or optional, a "mandatory- attribute 
shall be represented in an encoding that draws upon the 
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palette, while an "optional" attribute may, but need not, 
be represented. A nutnber is assigned, for encoding 
purposes, to each optional attribute. 
Note: No object is an example of a mix-in, 

5 2.2.4 Encoding Classes 

The encoding palettes admit encoding classes as 
described in Section 4.2 of this appendix. An "encoding 
class" is a predefined class -- beyond the "language 
classes" which are classes described in Appendix A of this 
10 disclosure that supports the Instruction Set for 

encoding purposes but is not part of the Instruction Set. 
HQtfi: An encoding class' only purpose is to define 
encoding attributes. Such a class has no 
initialization parameters, operations, 
15 ad^tations, or conversions. 

2.2t^ Encoding Attribiii ; ;.^ ^ 

The encoding palettes admit encoding attributes as 
described in Section 4.3 of this appendix. An "encoding 
attribute" is a predefined attribute beyond the 
"language attributes" which are described in Appendix A of 
this disclosure that supports the Instruction Set for 
encoding purposes but is not part of the Instruction Set. 
Every encoding attribute is a system instance attribute, 
N2££: An encoding attribute does not preclude the 

interface of a user-defined class from providing 
an attribute with the same identifier. 



20 



25 



Suui Attribute Encoding 

An "attribute encoding" encodes a predefined 
attribute and a reference to the attribute. 

30 2.3.; Forma 

An attribute encoding assumes one of these forms: 
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g A "boolean attribute encoding" encodes an instance of 

class "Boolean". 

Dial String 

5 A "dial string attribute encoding" encodes an 

instance of class "Dial String" . 

15 

An "integer attribute encoding" encodes an instance 
of class "Integer". 

^ 10 Item 

An "item attribute encoding" encodes an object or a 
reference to the object. 

25 List 

A "list attribute encoding- encodes an instance of 
15 class ''List" . 

30 

Octet Str-^T^q 

An "octet string attribute encoding" encodes an 
instance of class "Octet String" . 

35 

20 A "stack attribute encoding- encodes an instance of 

class "Stack" . 

40 

String 

A -string attribute encoding" encodes an instance of 
class "String". 

46 

25 2.3.2 Rules 

The form of the attribute encoding for an attribute 
^ shall be selected in accordance with the following rules, 



applied in the order given: 
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15 



20 



25 



30 



40 



1. An attribute encoding other than an item attribute 
encoding shall be selected if the attribute is an 
instance of the required class. 

2. An item attribute encoding shall be selected 
5 (otherwise) , 

2^ Reference Encodi^pg 

A "reference encoding" encodes a reference to an 
object that is encoded by an object encoding. 



10 



2r4> J- Bosnia 

A reference encoding assumes one of these forms: 



General 

A "general reference encoding" encodes a (protected 
or unprotected) reference that denotes an object by means 
of the "offset" in octets from the start of the reference 
15 encoding to the start of the object encoding. The offset 
is positive or negative if the object's encoding follows 
or precedes the reference's, respectively. Offsets shall 
be negative; positive offsets are reserved. 

Vaide^ 

^ 20 A "voided reference encoding" encodes a reference 

that is voided. 



An "interchange reference encoding" encodes a 
reference that denotes an interchanged object by means of 
25 both the object's digest and a citation to the class of 
45 which the object is an instance. 

Class 

A "class reference encoding** encodes a reference that 
^ denotes a class by means of either the class' numeric 
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code, if the class is predefined, or a citation to the 
class, if the class is user-defined. 

Procedure 

A "procedure reference encoding" encodes a reference 
5 to a procedure that is in the implementation of a 

user-defined class. A procedure reference encoding shall 
be used to encode only the "procedure" attribute of a 
predefined frame, F. A procedure reference encoding 
expresses, by means of an integer, the procedure's 

10 position in the "procedure" attribute of the procedure 
frame, «B", just below "P" in the -frames- attribute of 
which -F" is an item. The integer is either the position 
itself, if the integer is greater than or equal to one, oi 
one plus the arithmetic difference between the position, 

15 the minuend, and the "position" attribute of F, the 
subtrahend, otherwise. 

The form of the reference encoding of a reference to 
an object shall be selected in accordance with the 
20 following rules, applied in the order given: 

1. A voided reference encoding shall be selected if the 
reference has been voided. 

2. A class reference encoding shall be selected if the 
object is a predefined class. 

25 3, A general reference encoding shall be selected if the 
object is encoded as part of the teleparcel, rather 
than presumed present at the teleparcel 's 
destination. 

4. A class or procedure reference encoding shall be 

3 0 selected if the object is a user-defined class or a 

procedure in a user-defined class implementation, 
respectively . 

5. An interchange, reference encoding^ shall be selected 
(otherwise) . 
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No£s: Thus Rule 3 applies iff the object is encoded as 

part of the teleparcel, rather than presumed 
present at the teleparcel 's destination. 

1 ENCODING SPECIFXrATTOMg 
5 Teleparcels are defined in this section of this 

appendix. Subsections are devoted to teleparcels and to 
object, attribute, and reference encodings. 

1^ Convent inn? 

A teleparcel is a series of tokens, each of which is 
10 zero or more octets. The teleparcel is the octet string 
obtained by concatenating the tokens. 

A teleparcel obeys the syntactic, and accompanying 
semantic, rules below. Given in BNF (Backus-Naur or 
Backus normal form), the rules surround optional tokens by 
15 brackets ("t" and "] ") . 

Table B.l assigns codes to the forms of object and 
reference encoding. These codes are used as tags in the 
sections below. 



TABLE B.l 

-50 ProcedureReference 

-51 InterchangeReference 

- 52 UnprotectedRef erence 

-53 PredefinedClassRef erence 

-54 ProtectedRef erence 

-55 Protect edobject 

-56 - 

-57 - 

-58 UserDefinedClassRef erence 

- 5 a VoidedRe f e rence 

-SO Mixins 
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US^S.: The sections below follow the conventions of 

Sections 5.1 and 5.3 of Appendix A of this 
disclosure. 

3^ Teleoarcel 
S A teleparcel obeys this rule: 

Teleparcel ::m unsignedNumber unsignedNumber Object 

The first and second "unsignedNumber" encode the 
number of the major and minor versions of the Encoding 
Rules to which the teleparcel conforms, respectively. 
10 "Object- encodes the teleparcel 's subject and the 
subject's components. 

N2££: The numbers of the major and minor versions of 

the Encoding Rules that this appendix defines 
are 0 and 5, respectively, 

15 1^ Obi set: RT^^r.rfH,^^ 

An objects encoding obeys this rule, which reflects 
the defined forms: 

Object ::= ExecutedObject j Predef inedObject 

I UserDef inedObject | ProtectedObject 

20 3.3,1 Execut>»H OVf-j^^Tf 

An executed object encoding obeys the rule set out in 
Sectins 5.1 and 5.3 of Appendix A of this disclosure. 

The tag that is the first token in ExecutedObject - 
identifies the object as executed and reveals the object's 
25 class by encoding twice the class' code. 

N2£a: An executed object is encoded as in a binary 
telescript. 

^-i^ Predef in«.r^ ^hit^TTt, 

A predefined object encoding obeys this rule: 
30 Predef inedObject : := tag Palette 
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The tag identifies the object as predefined and 
reveals the object's class by encoding twice the class' 
code. The "Palette" draws upon the primary encoding 
palette for the class of which the object is an example. 

5 3-3.? User-defined Qb-iftrr 

A user-defined object encoding obeys this rule: 
UserDefinedObject : [Palette Mixins] tag Item Item 
Palette Mixins ; ; =, tag 

The first "tag" identifies the object as user-defined 
10 and reveals the class of which the object Is an example by 
encoding one plus twice the class' code. 

The first "Item" encodes the object's class, the 
second a list whose items correspond to the user-defined 
implementation superclasses of that class in their 
15 canonical order. Each item is itself a list, a list of 
the properties of the instance native to the class to 
which the item corresponds, in the order of their 
identifiers in the "properties" attribute of the class' 
implementation. The final one or more properties can be 
20 omitted, in which case nils are implied. 

The first "Palette" draws upon the secondary encoding 
palette and is present iff "Mixins" is present. The 
second "Palette" draws upon the primary palette for the 
class of which the object is an example. 

25 Protected O^fi^t; 

A protected object encoding obeys these rules: 
ProtectedObject ::- tag ProtectedObject Itself 

ProtectedObject Itself ::= ExecutedObject | 

Predef inedObjecc j 
•^^ UserDefinedObject 
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The "tag" identifies the reference as protected. The 
"ExecutedObject", the "PredefinedObject", or the 
"UserDefinedObjecf encodes the object. 

1^1^ Paletfcg 
5 An encoding palette's encoding obeys these rules: 

Palette : Attributes [Mask Attributes] 
unsignedNumber 
[Attribute Attributes] 



Mask 
Attributes 



The first "Attributes" encodes the zero or more 
10 attributes that the palette declares mandatory, in the 
order in which they are listed in the table that defines 
the palette. The table fixes the number of occurrences of 
"Attribute". 

The "Mask" and the second "Attributes" are present 
IS iff the palette declares any attributes optional. The 
second "Attributes- encodes zero or more of the optional 
attributes. The -Mask" fixes the number of occurrences of 
"Attribute" . 

The "Mask" encodes an integer indicating which 
20 optional attributes the second "Attributes" encodes. The 
palette's table numbers the optional attributes in the 
range of (1, n] . The second "Attributes" includes an 
encoding of the attribute numbered "i" iff the bit in the 
integer's representation weighted 2" is one. The 
25 attributes actually encoded appear in the second 

"Attributes" in order of increasing "i". Bits logically 
required by "n- but physically absent from "Mask" shall be 
considered zero. Bits physically present but logically 
not required shall be ignored. 



30 lil Attrih^l^A EnffftriiTig 

An attribute encoding obeys this rule, which reflects 
the defined forms: 
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15 



20 



25 



30 



Attribute Boolean j DialString ( 

Integer | 

Item I List | OctetString | 

String 

5 3.4.1 Boolean 

A boolean attribute encoding obeys this rule: 
Boolean : : = empty 

The boolean attribute encoding is present iff the 
boolean is "true". 
10 IlQtfi: The encoding's presence is indicated by the mask 

that encompasses the encoding. 
Hfitfi: Thus a palette's boolean attributes are 

necessarily optional. 

iL±^ Dial Sr^r^nq 

15 A dial string attribute encoding obeys this rule: 

DialString OctetString 



The "OctetString" encodes the octet string, "0", 
determined by the list, "L", of nibbles determined in turn 
by the dial string, "D", and having the same length, 
35 20 A nibble of "L'» encodes unsigned the integer in the 

range [0, 14] determined by the character of "D" at the 
same position. The numerals (-0'»-"9") determine 0-9, a 
dash (".") determines 13, and a space (» ") determines 14. 
40 The nibble of "L" at position 2i-l or 2i, "i" being at 

25 least one, occupies Bits 7-4 or 3-0, respectively, of the 
octet of "O" at position «i". Bit 7 or 3, respectively, 
is the MSB, Bit 4 or 0, respectively, the LSB. Iff the 
^ length of "D" and thus "L" is odd. Bits 3-0 of the last 

octet of "0" encode 15 in the same way. 
30 Hatfi: Thus a dial string is encoded in a form of 
50 Binary Coded Decimal (BCD) . 
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35 



40 



48 



55 



3.4.3 Integer 

An integer attribute encoding obeys this rule: 
Integer signedNumber 

The "signedNumber" encodes the integer, 
5 Nptg: This is a binary telescript encoding of an 

integer, except that the initial token, 
identifying the encoding as an integer's general 
encoding, is absent. 



3-L±L± Item 
10 An item attribute encoding obeys this rule: 

20 Item ::= Object | Reference 

The "Object" or "Reference" encodes the object or a 
reference to the object, respect ively. 



15 A list attribute encoding obeys these rules: 

List unsignedNumber Items 

Items ::a [Item Items! 

The "unsignedNumber" and "Items" together encode the 
list. The former encodes the number of occurrences of 
20 "Item" in the latter, which in turn encode the items of 
the list in order of increasing position. 

IjlA^ Octet String 

An octet string attribute encoding obeys this rule: 
OctetString ::= unsignedNumber Octets 



25 The "unsignedNumber" and "Octets" together encode the 

octet string as specified in Section 5.3.2 of Appencix A 
of this disclosure, 
^ NS£e: This is a binary telescript encoding of an octet 

string, except that the initial token. 
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10 



15 



identifying the encoding as an octet string's, 
is absent. 

3.4.7 Stack 

A stack attribute encoding obeys the same rules as a 
5 list attribute encoding, except that the items of the 
stack are encoded in order of decreasing position. 

3.-^.8 String 

A string attribute encoding obeys this rule: 

String unsignedNumber characters 

20 10 The "unsignedNumber" and "characters" together encode 

the string as specified in section 5.3.2 of Appendix A of 
this disclosure. 

liate: This is a binary telescript encoding of a 

string, except that the initial token, 
15 identifying the encoding as a string's, is 

absent . 

30 

1^ Reference Encoding 

A reference encoding obeys this rule, which reflects 
the defined forms: 
35 20 Reference ::- GeneralRef erence ( 

VoidedReference | 
InterchangeRef erence | 
ClassReference | 
ProcedureRef erence 



25 



40 



45 



25 3t5il General Referengg 

A general reference encoding obeys these rules. One 
encoding is defined for unprotected references, another 
for protected references: 

GeneralRef erence UnprotectedRef erence | 

so 30 ProteccedRef erence 

UnprotectedRef erence : : » tag signedNumber 
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ProtectedReference ::= tag signedNumber 

The "tag" identifies the general reference as such 
and as either unprotected or protected. The 
"signedNumber" encodes the offset from the reference 
encoding to the object encoding of the referenced object. 

1^-5^ Voided Referenr^ 

A voided reference encoding obeys this rule: 
VoidedRef erence : : - tag 

The "tag" identifies the voided reference as such. 

Interchange Ref eip^n<7«=^ 
An interchange reference encoding obeys this rule: 
InterchangeRef erence tag Item Item 

The "tag" identifies the interchange reference as 
such. The first "Item" encodes a citation to the 
interchanged object's class. The second "Item" encodes 
the interchanged object's digest. 

Class Refergni^^ 
A class reference encoding obeys these rules. One 
encoding is defined for predefined classes, another for 
user-defined classes: 

ClassRef erence ::= PredefinedClassRef erence | 

UserDefinedClassRef erence 
PredefinedClassRef erence ::= tag unsignedNumber 

UserDefinedClassRef erence tag Item 

The "tag" identifies the class reference as such and 
the class as either predefined or user-defined. If the 
class is predefined, the "unsignedNumber" encodes the code 
assigned to the class either in Section 5.4,1 of Appendix 
A of this disclosure or in Table B.2, below, of this 
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appendix. If the class is user-defined, the "Item- 
encodes the class' citation. 



10 



15 



3^5,5 Procedure Referi>nrff 

A procedure reference encoding obeys this rule: 
5 ProcedureReference : :« tag signedNumber 

The «tag" identifies the procedure reference as such. 
The "SignedNumber- identifies the procedure's position as 
previously described. 



20 



25 



30 



A ENCODING CLASSES AJ ^ ATTRTRrTXR <? 

10 Telescript's encoding classes and attributes are 

defined in this section of this appendix. A subsection is 
devoted to first the encoding of classes and then the 
encoding of attributes. 

Conventiona 
15 Encoding r^^^^Af;^ 

The encoding classes form a group. The section below 
that defines this group follows the conventions, e.g., of 
Section 3.2 of Appendix A of this disclosure. 



35 


20 


Table B.2 assigns identifier codes to the encoding 
classes. 










TABLE a,^ 








144 


CatchFrame 


40 




145 


CollectionStream 






146 






25 


147 


Prede f inedFrame 


46 




148 


GoFrarae 






149 


RepeatFrame 


50 




150 


RestrictFrame 
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10 



151 
152 
153 



171 



SendFrame 
UseFrame 

UserDe f inedFr ame 



WhileFrame 



IS 5 Note : 



20 



25 



Not^ : 



10 



Classes -Frame" and "Procedure Frame" require no 
codes because they are abstract. Class "Dial 
String- requires no code because its instances 
have their own encodings. 

Because an encoding class' only purpose is to 
define encoding attributes, this appendix does 
not devote a major section to each encoding 
class, even though Appendix A devotes such a 
section, e.g.. Section 4.2 to every language 
class. " 



30 



35 



40 



45 



SO 



15 Encoding Attrihu^gg 

The encoding attributes are native to certain 
language and encoding classes. The section below that 
defines the encoding attributes devotes a subsection to 
each predefined class to which such attributes are native 

20 The classes are considered in alphabetical order. An 
encoding attribute's definition follows the conventions 
established in Section 4.1 of Appendix A of this 
disclosure . 

Identifier codes need not be assigned to the 
25 encoding attributes. 

1^ Encoding HyrMip 

Object (Referenced) 

• Collection 

• • List (Ordered) 

• • • Constrained List (Constrained) 
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30 



35 



40 



45 



50 



10 



15 



Frame 



• 
• 



String (Cased & Executed) 
• Dial String 



Procedure Fr;^r^o 

• Predefined Frame 



Repeat Fram^ 
Restrict Fram^ 
Use Frame 
While Frame 

• User-defined Fram#> 

Qq Frame 

• Send Frame 
Stream 

• Collection stream 



4.2.1 Catch Fram>3 

Attributes 

A "catch frame" is a predefined frame whose subject 
20 method is the method for "catch" and whose "procedure" 
attribute is the operation's responder. 

A catch frame's native attribute is the class that is 
the operation's argument (attribute "exception") . 

4 .2r^ Collecti on Stream 

25 Att;rj,l?ut;^9 

PoaitiQn 
sourg^ 

A "collection stream" is a stream whose items are 
those of a collection . 

A collection stream's native attributes are the 
stream's source (attribute ''source") and the stream's 
current position (attribute "position"). The -source" is 
the collection whose items the collection stream produces. 
The "current position" is a position in the "items" 
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attribute encoding the collection stream's source. The 
collection stream last produced the item at the stream's 
current position, previously produced any items at 
positions before the current position, and has yet to 
5 produce any items at positions after the current position. 
Note: A collection stream is the result of the 

"stream" operation when the latter is performed 
by a collection. 



10 



^i2f 3 Dial String 

A "dial string" is a string each item of which is 
either a numeral ("0"-"9"), a hyphen ('•-"), or a space {" 
") . 

Hatfi: Dial strings are used in telenumbers, 

15 A "frame" is an object recording the current state of 

a performance of a predefined or user-defined method, the 
frame's "subject method". 

4^2^ Go Fr^mg 

A "go frame" is a frame entailing the taking of a 
20 trip. The method is the predefined method for either 
operations "go" or "send", the former in the case of an 
instance of this class, the latter in the case of an 
instance of this class' subclass. 

^•^>$ Predefin^g^ Py^^r^^ 

25 A "predefined frame" is a procedure frame whose 

subject method is predefined, and thus whose procedure is 
not that method. The subject method of an instance of 
this class is the method for operations "do", •either", 
"if", "loop", or "select", 
30 Hotfi: Which of the above operations applies is 

determined by examining the identifier by means 
of whose execution the operation was requested. 
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4.2,7 Procedure Frame 

5 

position 
procedure 

5 A "procedure frame" is a frame entailing a 

to procedure's performance. 

A procedure frame's native attributes are the 
procedure being performed (attribute "procedure") and the 
procedure's current position (attribute "position"). A 
10 procedure's "current position" is that of the item the 
Engine is currently executing. 

Nats: The procedure i& either the "procedure" 
^ attribute of the subject method, the responder 

of the feature the method implements, or an 
15 argument of the feature. 

Attributes 

reoetitionfl 
^ repetitionff.cir^ipar- 

2 0 A "repeat frame" is a predefined frame whose subject 

method is the method for operations "repeat" and whose 
"procedure" attribute is that operation's responder. 
J5 A repeat frame's native attributes are the number of 

performances of the frame's "procedure" attribute, 
25 including the current performance, that have been 
^ initiated (attribute "repetitionsSoFar-) , and the number 

requested at the outset (attribute "repetitions"). 

^t2,9 Restrict Frami^ 

9 Attributes 

A "restrict frame" is a predefined frame whose 
subject method is the method for operations "restrict" and 
whose "procedure" attribute is that operation's argument. 
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A restrict frame's native attribute ia the permit the 
5 subject held at the start of the Engine's performance of 

the subject method (attribute "permit") . 

^i2.1Q Send Frame 
10 5 Attribut^a 

ti^cke^s 

A "send frame" is a go frame whose subject method is 
the predefined method for operations "send". 

A send frame's native attribute comprises one or more 
10 of. the tickets originally in the operation's argument 
(attribute "tickets"). 



IS 



20 



25 



30 



"^,^.11 Us^ Fr^mg 
Attributes 

resource 

15 A "use frame" is a predefined frame whose svibject 

method is the method for operations. "use* and whose 
"procedure" attribute is one of the operation's arguments. 

A use frame's native attribute is the operation's 
responder (attribute "resource"). 

20 ±^2^ User-defined T^^^^^ 
35 At;tyibutsa 

resDonder 
stack 
variablefl 

25 A "user-defined frame" is a procedure frame whose 

procedure is that of the frame's subject method. The 
subject method is user-defined and is necessarily a value 
^ of an implementation's "instanceMethods" or "setMethods" 

attribute. 

A user-defined frame's native attributes are the 
method's responder (attribute "responder"), stack 
(attribute "stack"), and variables (attribute 
"variables"), the latter in the order of their identifiers 
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in the method's "variables" attribute. The responder is 
the agent of whose "frames" attribute the user-defined 
frame is an item. 

N^te: Let "I", if any, be an item in the "procedure" 

5 attribute of the frame, "B", if any, below the 

user-defined frame in the agent's "frames" 
attribute. In particular, let "I" be the item 
whose position in the "procedure" attribute is 
the "position" attribute of "B". "I" is either 

10 (a) non-existent: the subject method is for 

operations "live"; (b) an identifier preceded by 
a "setAttribute" modifier: the subject method is 
a value in an implementation's "setMethods" 
attribute; (c) an identifier not so preceded; 

15 the subject method is a value in an 

implementation's "instanceMethods" attribute; or 
(d) an "escalate" selector: the subject method 
is as described in either (b) or (c) above. 

4,2tX3 While Framg 
20 At^tyilpute? 

isPrecondii^j,^!^ 

A "while frame" is a predefined frame whose subject 
method is the method for operations "while" and whose 

25 "procedure" attribute is that operation's responder. 

A while frame's native attributes reveal the executed 
object that is the operation's argument {attribute 
"precondition") and whether the argument, rather than the 
responder, is* being performed (attribute 

30 "isPrecondition") . The while frame's "position" attribute 
pertains to whichever of the two procedures is being 
performed. 

Encoding Attribute^ 

The encoding attributes are defined below. 
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4^3_a Agent 

Native to this class are the following encoding 
attributes. 



frames : 

10 sealed Stack [Frame] ! / 

The responder's pending frames. The bottom frame's 
subject method is a user-defined method for operations 
"live". The top frame's subject method is the built-in 
method for operations "go" or "send". There are zero or 
more other frames , 



IS 



20 



30 



35 



40 



45 



so 



nativePermit. 

sealed copied Permit) Nil ; 



25 Either the responder's native permit, if it differs 

from the permit the responder holds, or a nil, otherwise. 



15 J,JL2 Catch Fr^pff 

Native to this class is the following encoding 
attribute, 

exception ; 
sealed Class; 

20 The class — either class "Exception" or a subclass 

thereof that is performing the responder's s\ibject 
method. 

^^3,3 ColleffM'oi^ 

Native to this class is the following encoding 
25 attribute. 

itemg ; 

sealed List [Object] • ; 
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10 



15 



20 



25 



30 



35 



40 



The responder's items. The position of any 
particular item is undefined. 

^'3.4 Collection Strgam 

Native to this class are the following encoding 
5 attributes. 

position ; 

sealed Integer [Nil; 

Either the current position in the responder, if the 
responder has produced neither none nor all of its items, 
10 or a nil, otherwise. 

SQ^yg^ ; 

sealed Collection [Object] |Nil; 

Either the responder's source, if the responder has 
not produced all of its items, or a nil, otherwise. 

15 4LJLi Dictionary 

Native to this class is the following encoding 
attribute. 

a33Qciati9p?- 

sealed List [Object] ! ; 



20 The keys and values that form the responder's items. 

The items at positions 2i-i and 2i of the list are a key 
and its associated value, respectively. The position of 
45 any particular key- value pair is undefined. 

4>3.6 List 
25 Native to this class is the following encoding 



50 



attribute. 
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items : 

sealed List [Object] !; 
The responder's items . 



^■3.7 Pattern 

Native to this class is the following encoding 
attribute . 



t5 text : 

sealed copied String; 

^ The responder's text. 

10 4,3,8. Procedure Pr^r^^ 

Native to this class are the following encoding 
attributes, 

position ; 

^ sealed Integer; 

15 The current position in the responder's "procedure" 

attribute. 

^ EtrsSedtLrg: 

sealed Procedure; 

^ The procedure whose performance the respondef 

20 entails. 



4.3.9 Random Strean^ 

46 

Native to this class is the following encoding 
attribute. 

50 seed : 

25 sealed Integer; 
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10 



15 



25 



30 



35 



Either the responder's seed, if the responder has not 
produced an item, or the item the responder produced last, 
otherwise. 

4.3.10 Rfip«sat; Fyam^ 
5 Native to this class are the following encoding 

attributes. 

:cepqt;i,t;Agng: 
sealed Integer; 



The number of performances of the responder's 
20 10 "procedure" attribute requested of the responder's subject 
method via the argument of operations "repeat". 



repetitionsSoFar: 
sealed Integer; 

The number of performances of the responder's 
15 "procedure" attribute, including the current performance, 
initiated so far. 

4.3.11 Restrict Frame 

Native to this class is the following encoding 
attribute. 



20 Q^miL: 
^ sealed copied Permit; 

The permit the subject held at the start of the 
performance of the responder's subject method. 

46 



50 



4 .3 .12 ^end Frame 
25 Native to this class is the following encoding 

attribute . 
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10 



tickets : 

sealed List [Ticket] ! ; 

One or more of the tickets in the list supplied as 
the argument of the responder's subject method. The 
5 position of any particular ticket is \indefined, 

4 .3 .13 Stack; 

Native to this class is the following encoding 
attribute. 

^ 10 sealed stack [Object] ! / 

The responder's items. 

25 4 . 3 .14 Time 

Native to this class are the following encoding 
attributes, 

30 

15 dst : 

sealed Integer; 

35 The "dst" attribute of the calendar time that would 

have been produced, when and where the responder was 
produced, by requesting "new" of class "Time" and 
20 converting its result to a calendar time. 



40 



46 



so 



sealed Integer; 

The "second" attribute of the unnormalized calendar 
time that denotes the same absolute point in time, "T", as 
25 does the responder, but that would denote time "Tq" if its 
"second" attribute alone were set to zero. 
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Note : To is the time relative to which all times are 
measured. It coincides with the start of a 
* minute in the Gregorian calendar. This 

attribute, then, is the number of seconds that 
5 separate T from To- The attribute is strictly 

positive or negative if the time follows or 
precedes To, respectively. 

zone : 

15 sealed Integer; 



10 The "zone" attribute of the calendar time that would 

have been produced, when and where the responder was 

20 

produced, by requesting "new" of class "Time" and 
converting its result to a calendar time. 

15 Native to this class is the following encoding 

attribute, 

30 

yei^pyyce : 
sealed Resource; 

35 The resource performing the responder' s subject 

20 method. 



40 



^>3'1$ User-defined Frame 

Native to this class are the following encoding 
attributes. 



^ regpop4er; 

25 sealed Object; 



50 



The responder of the responder' s subject method. 
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sealed Stack (Object] !; 

5 

The stack of the responder's subject method. 

10 sealed List [Object] ! ; 

5 The variables of the responder's subject method. 

4>3r;7 While Frame 

Native to this class are the following encoding 
attributes, 

.i,?Prec9i^qL3,tj,oa: 
10 sealed Boolean; 

Whether the responder's "precondition" attribute, 
rather than its "procedure" attribute, is being performed. 

prg^oqdAtitOTH; 
sealed Executed; 

15 The argument of operations "repeat". 

35 5 ENCQDTWG PALLETTRfi 

Telescript's encoding palettes are defined in this 
section of the appendix. One section is devoted to 
language classes, another to encoding classes. All 
20 Engines of a network must agree on the following: (i) the 
method by which an assigned teleaddreas' "provider" 
attribute is selected, and (ii) the method by which an 
assigned telename's "authority" attribute is selected. 
One embodiment of each of these methods is implemented in 
25 the computer software included as Microfiche Appendix G of 
this disclosure. 



15 



20 



25 



30 



40 



45 



SO 



5^ Conventions 
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A subsection is devoted below to each predefined 
flavor whose examples are encoded using a non-empty 
primary palette. First the language flavors and then the 
encoding flavors are considered in alphabetical order. 
5 One additional subsection, entitled Mix-in, is devoted to 
the one secondary palette . 

Most every palette is defined using a table whose 
columns are labeled, and whose rows define predefined 
attributes, as follows. 
10 • ft- Either "M", if the attribute is mandatory, 

or the number assigned to the attribute, if 
the attribute is optional. 

• Attribute . The attribute's identifier, 

• Sender . The attribute's type, defined using the 
15 notation of Section A. 2. 4 of Appendix A. 

If the type is "Boolean" cuid just one of 
its two instances is permitted, "true" or 
"false" appears in lieu of "Boolean". 

• S^geiver- Either a dash («-"), if a sending Engine 
20 shall not omit the attribute from an 

encoding, or the instance of the type that 
the receiving Engine shall supply if the 
sending Engine does omit the attribute, 
otherwise . 

25 ^ Language Clasggg 

The encoding palettes for the language classes are 
defined below. 

Ho£a: The absence from this section of certain 

language classes is explained as follows. An 
^0 object's glffiga and isProtected attributes 

figure in its encoding, but not as attributes. 
An object computes its size attribute. A place 
is immovable and thus not encoded. A process' 
class is not user-defined unless the process is 



421 



EP 0 634 719 A2 



10 



an agent or a place. A stream computes its 
"current", "isDone", and "next" attributes. 

5.2.1 Agent 

An example of this class is encoded using the primary 
5 palette in Table B.3, 



15 



20 



25 



30 



35 



40 




*Thi3 attribute shall be supplied by either the sending 
Engine, if the agent is transferred within a domain, or 
the receiving Engine, otherwise. 
'The "priority" attribute of the agent's "permit - 
20 attribute. 

LxAjlI Associaf^r^n 

An example of this class is encoded using the primary 
palette in Table B.4. 



50 



25 



table; b.4 


I j Attribiit-P 


Sender 


Receivei;- 
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M 


"key" 


Object 




M 


"value" 


Object 


1 



Attribute 

An example of this class is encoded using the primary 
5 palette in Table B.5. 



10 





TABLE B.5 




t 






Receiv^^- 




"exceptions " 


Set [Identifier!]* 


Cleared 




"isPublic" 


true 


false 




"constraint " 


Constraint 


See Constraint j 




"isSet" 


true 


false 



*In a class, this is "Set [Class]". Each class is cl 
^ "Exception" or a subclass thereof. 



5«2,4 C^XencA^ir Time 

An example of this class is encoded using the primary 
palette in Table B.6, 





TABLe; 


I 


Attributi* 




Rec?i,v?r 


1 


"day" 


Integer 


Nil 


2 


"dayOfWeek" 


Integer 


Nil 


3 


"dayOfYear" 


Integer 


Nil 


4 


"dst" 


Integer 


Nil 


5 


"hour" 


Integer 


Nil 
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10 







6 


"minute" 


Integer 


Nil 


7 


"month" 


Integer 


Nil 


8 


"second" 


Integer 


^ 1 


9 


"year" 


Integer 


Nil 1 


10 


"zone" 


Integer 





5.2,5 atation 

An example of this class ia encoded using the primary 
palette in Table B.7, 



30 



TABLE B.7 | 


t 




Sender 




M 


"title" 


Identifier! 




1 


"author" 


Telename 


Nil 


2 


"majorEdition" 


Integer 


Nil 


3 


" minorEdi t ion" 


Integer 


Nil 



15 5.2.6 Claa^ 

An example of this class is encoded using the primary 
palette in Table B.8, 

40 



TABLE B.fl 



46 




1 


Attribute 


Sender 






20 


M 


"citation" 


Citation 




50 




M 


"interface" 


Interface 


- 
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10 




'implementation" 



Implementation 



Nil 



3 



IS 



Class Definltinr^ 

An example of this class is encoded using the primary 
palette in Table B.9. 



20 



25 



30 



35 



40 



45 




TABLE B.Q 



10 



1 








M 


"interface" 


Interface 




M 


"title"^ 


Identifier! 




1 


" impl ementat ion " 


Implementation 


Nil 


2 


"majorEdition" 


Integer 


1 


3 


"minorEdition" 


Integer 


1 



5^2,9 Collection 

An example of this class is encoded using the primary 
palette in Table B.IO. 



15 





TABLE B.IO 1 


I 




?«nder 


Receive^ | 


J_ 


"items" 


List (Object] ! 


Cleared 


52.? 


Conatrained Dictj^fi^^Tpy 





An example of this class is encoded using the primary 
20 palette in Table B,ll. 



50 
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10 





TABLE B.il 


t 


Attribut;^ 


Sendei; 




M 


"constraint" 


Constraint 


t — , 




"associations" 


List [Object] 





15 



5 5.2aP ConstrainArf t,!^^ 

An example of this class is encoded using the primary 
palette in Table B.12. 



20 



25 



30 



10 





TABLE 


I 


Attribute 




Receiver 




"constraint" 


Constraint 


M 


■ 


"items" 


List [Object] 





?t2, l l Constrain**f^ goh 

An example of this class is encoded using the primary 
palette in Table B.13. 



35 



40 



45 



15 





TABLE 9,13 




Attribute 


Sendeyp 


Receiy^r 




"constraint" 


Constraint 






"items" 


List [Object] 





^'2. 1 2 Constrairit 
20 An example of this class is encoded using the 

palette in Table B.14. 



primary 



50 



TAPLfi e.l4 
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5 



1 








1 


"is Instance" 


true 


false 


2 


"isOptional" 


true 


false 


3' 


"classid" 


Identifier I 


'Object 


3» 


"of Class" 


Class 


Object 1 


4 


"passage" 


Identifier! 


'byRef 1 



'in a class, the "classld" and "of Class" attributes are 
present implicitly and explicitly, respectively, the 
former being the "title" attribute of the latter's 

10 "citation" attribute. In a class definition and 

elsewhere, the "classid" and "of Class" attributes are 
present explicitly and implicitly, respectively, the 
latter being a nil. In either a class or class 
definition, the constraint is the "constraint" attribute 

15 of an attribute definition, the "result" attribute of an 
operation definition, or an item of the "arguments" 
attribute of an operation definition. In any of these 
cases, that feature definition is a value in the 
"classFeatures" or "inatanceFeatures" attribute of an 

20 interface. Finally, that interface is the "interface" 
attribute of the class or class definition. 



Si^r^? Contact 

An example of this class is encoded using the primary 
palette in Table B.15. 



25 



TABLE 1 


t 


Attribute 


Sender 


Receiver 


1 


"subject" 


Process 


Nil 


2 


"subjectClass" 


Citation 


Nil 
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1 TABLE B.15 j 




"subjectName* 


Telename 


Nil 




"aubjectNotes" 


Object 


Nil 1 



An example: of this class is encoded using the primary 
5 palette in Table B.16. 







TABL? ^,^5 


20 


1 


At^irilpuCQ 








M 


"associations" 


List [Object] ! 





5 '2 , 1 5 ImDlemen^■a^^CT 

An example of this class is encoded using the primary 
palette in Table B.17. 





table; b.;\7 


1 


Attrib^t€ 


ggndec 




1 


" classMethods " 


Lexicon [Method] 


Cleared 


2 


" fromMethode" 


Lexicon [Method]* 


Cleared 


3 


" instanceMethods " 


Lexicon [Method] 


Cleared 


4 


"properties" 


List [Identifier!] 


Cleared 


1 5 


"setMethods" 


Lexicon [Method] 


Cleared 


6 


"superclasses** 


List [Identifier!]^ 


Nil 


7 


"toMethods" 


Lexicon [Method] ' 


Cleared 


8 


"vocabulary" 


Lexicon [Citation] 


Nil 



a class, this is "Dictionary (Class, Method]", 
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^In a class, this is "List [Class] ■ . 



10 



^•'^^15 Interface 

An example of this class is encoded using the primary 
palette in Table B.18. 



IS 



20 



25 



10 





Si 19 


& 


Attribute 


Sendei;- 


Rece:^v5r 


1 


"class Features" 


Lexicon [Feattire] 


Cleared 


2 


** instamceFeaturea " 


Lexicon [Feature] 


Cleared 


3 


■isAbstract" 


true 


false 


4 


"sealedClasaFeaturea " 


Set (Identifier 1) 


Cleared 


5 


" sealedlns tanceFeaturas ** 


Set [Identifier I ] 


Cleared 


€ 


"superclasaes" 


List [Identifier I)* 


'Object 


7 


"vocabulary* 


Lexicon [Citation] 


Cleared 



30 



35 



40 



'The receiver supplies a list of one identifier, that of 
15 class "Object" . In a class, this is "List [Class] " , and 
the receiver supplies a list of one class, class "Object". 



An example of this class is encoded using the primary- 
palette with which an example of class "Dictionary" is 
20 encoded. 

Notfi: The "constraint" attribute of a lexicon is fixed 

by the Instruction Set. 



45 



An example of this class is encoded using the primary 
25 palette in Table B.19. 



so 



TABLE B.19 



55 



429 



BNSDOCID: cEP 0634719A2J_> 



EP 0 634 719 A2 



10 



15 



20 



25 



30 



3S 



40 



46 



1 












M 


"items " 


List [Object] • 





^-2^ Methot^ 

5 nalet^! "T^^ °' this cla« is encoded using the primary 
5 palette xn Table B.20. ^ i 





Attribute 


TABLE R.::;^^ 
Sender 




1 


"procedure" 


Procedure 


£eceiv<»i^ 
Cleared 


2 


"varicOjles" 


List [Identifier I J 


Cleared 



10 S-^t^Q. Mix-in 

The secondary palette is that in Table B.21. 



15 



TABLR p,;>T 



A hashed object's "hash- attribute and an 
interchanged object's "digest- attribute are 
computed by the object, 

20 Qperat^.^n 

An example of this class is encoded using the primary 
palette in Table B.22, a «e primary 







Sende;^ 




1 


"citation" 


Citation 


Absent 


2 


"constraint" 


Constraint 


Absent 


3 


name 


Telename 


Absent 



so 
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10 



15 



20 







TABLE ?,5>:^ 




Attribute 




Receiver 


1 


excections 


Set [Identifier!]* 


Cleared 


2 


isPublic 


true 


false 






List [Constraint] 


Nil 




result 


Constraint 


Nil 



*In a class, this is "Set [Class] " . Each class is Excepti 
or a subclass of it. 



a.on 



25 



10 An example of this class is encoded using the primary 
palette in Table B.23. 



30 



35 



15 



TABLE 



£ 




Sender 


Mfei^v^C 


M 


"citation" 


Citation- 




M 


"items" 


List [Class] - 





40 



45 



50 



UQ^: The "constraint" attribute of a package is fixed 

by the Instructor Set. 

An example of this class is encoded using the primary 
20 palette in Table B.24. 





TABLE p,24 




Attribqte 


Sei>4^7 


Receiv^iT 


r 


"text" 


String 
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5 



10 



5t2.2A Permit 

An example of this class is encoded using the primary 
palette in the table. 



15 



20 



25 



30 



35 



40 



45 



50 



10 







TABLE B.;^5 


& 


Attribute 


Sender 




1 


allowance 


Integer 


Of subject 


2 


canCharge 


true 


false 




canGo 


true 


false 


4 


canProcreate 


true 


false 


5 


canRestart 


true 


false 


6 


canSend 


true 


false 


7 


cauiTerminate 


true 


false 


, 


deadline. 


Time 


Of subject 




9 


priority 


Integer 


Of subject 



15 5,2,25 BsfilMaa 

An example of this class is encoded using the primary 
palette in the table. 



20 



TABLE E.-X^ 



t 


A££X?-but£ 


Sender 




X 


"agentClass" 


Citation 


Nil 


2 


"agentName" 


Telenarae 


Nil 


3 


"maximumWait" 


Integer 


Nil 
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IS 



20 



25 



30 



35 



5.2,2g Random Stream 

An example of this class is encoded using the primary 
palette in Table B.27. 



An example of this class is encoded using the primary 
palette in Table B.28. 



10 



^The "conditions" attribute comprises one identifier which 
15 equals the "condition" attribute. This identifier is 
undefined. 

JJofce: Any processes other than the subject awaiting 

use of the resource when the subject began its 
trip await the resource no longer, having been 
20 left behind. 





TABLE B.27 | 


I 




Sei>4e2r 




M 


"seed" 


Integer 













I 


Attribute 




Receiver 










1 




"condition" 


Identifier I 


Undefined* 


2 


" conditions" 


Set [Identifier!] 


Undefined^ 



40 5.2.28 

An example of this class is encoded using the primary 
palette with which an example of class "Collection" is 
encoded . 



50 



25 5 a,2? stasdi 

An example of this class is encoded using the primary 
palette in Table B.29. 
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TABLE B.29 



Attribmi^ 



* items " 



Stack [Object] ! 



Receiver 



5,2,30 Teleaddref?^ 
5 An example of this class is encoded using the primary 

palette in Table B.30. 







1 






Receiver 


M 


"provider" 


OctetString 


— 


1 


"location" 


String 


Nil 


2 


" rout ingAdvice " 


List [OctetString] 


Cleared " 1 



LO 



5.2.31 Telenami> 

An example of this class is encoded using the primary 
palette in Table B.31. 







TMLE B,31 




1 


Attribute 


Sender 




M 


"authority" 


OctetString 




1 


"identity" 


OctetString 


1 



?r?T33 Telenumbf>r 

An example of this class is encoded using the primary 
palette in Table B.32. 



TABLE H 10 
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5 





Attribute 




Receiver | 


M 


"country" 


DialString 




M 


"telephone" 


DialString 




1 


"extension" 


DialString 


Nil 1 



15 



5 Ticket 

An example of this class is encoded using the primary 
palette in Table B.33. 



30 



15 







r— =1 


t 


Attribute 


ggndec 


RecGiveir 1 


1 


"travelNotea" 


Object 




2 


"way" 


Way 


Nil 






"desiredWait" 


Integer 


Nil 




4 


" de s t ina t i onAddr e s s " 


Teleaddress 


Nil 




5 


" destinationClass" 


Citation 


Nil 




6 


" de s t ina t i onName " 


Telename 


Nil 




7 


"destinationPermit ■ 


Permit 


Nil 




a 


"maximumWait " 


Integer 


Nil 





40 



Ticket Stub 

An example of this class is encoded using the primary 
20 palette in Table B.34. 



46 




TABLE B,3^ 




I 


AttJTibMte 


Sender 


Receivet: 


SO 1 


1 


"travelNotes" 


Object 


Nil . 
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10 




15 



20 



25 



5.2.3^ Time 



An example of this class is encoded 



palette in Table B,35. 



using the primary 





TABLE B.3=: 




Attribute 


Sendej 


Receivi;r 


1 


"dst" 


Integer 


0 


|2 


"second" 


Integer 


0 1 


[3 


" zone " 


Integer 


° 1 



30 



35 



10 . ^.;5,3^ Trip Eic^^pn^^ 

oalet^ "Ti? ''''' " """"^"^ """^ P---y 

palette m Table B.3e. r- jr 



15 







S.^ndft£ 


M 


"ticketStub" 


TicJcetStub 



Receiver 



Nil 



40 



46 



SO 



An example of this class is encoded 
palette in Table B.37. 



using the primary 
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5.2.38 Way 

An example of this class is encoded using the primary 
palette in Table B.38. 





TABLE S,3S | 


1 


Att;?rii?Mt9 


Sender 


Receiver 


1 


"authenticacor" 


Authenticator 


Nil 


2 


"means" 


Means 


Nil 


3 


"name" 


Telename 


Nil 





^ Encoding Classeq - ^ 

The encoding palettes for the encoding classes are 
defined below. 



5-3>; Catch Framq 

An example of this class is encoded using the primary 
palette in Table B.39. 



15 





TABLS S.?? 




Attribute 


Sender 


Egc^iv^r 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 




M 


"exception" 


Class 





20 5, 3 1 , 3 collection <;rr>aan. 

An example of this class is encoded using the primary 
palette in Table B.40. 



TABLE B.4Q 
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Sendei; 


Receiver 




"position" 


Integer 


Nil 


2 


"source" 


Collection [Object] 


Nil 



15 



20 



25 



■5-? -3 Predefing^ Fr^TTIft 

5 An example of this class is encoded using the primary 



palette in Table B.41. 



10 





TABLE B.41 "] 


£ 


Attribute 




Receiver 1 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 





5«3.i Repeat Franks 

An example of this class is encoded using the primary 
30 palette in Table B.42. 



35 15 





TABLE B--^2 


t 




Sender 


Recei,Ye?r 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 






"repetitionsSoFar" 


Integer 






"repetitions" 


Integer 





45 

20 Restricts w^^^^ 

An example of this class is encoded using the primary 
palette in Table B.43. 

50 
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10 



15 




20 



25 



Send Fram** 



An example of this class is encoded using the primary 
palette in Table B. 44. 



10 





TABLE B-44 | 


t 


Attribute 


Sender 




M 


"tickets" 


List [Ticket] 1 





30 



35 



40 



46 



SO 



An example of this class is encoded using the primary 
palette in Table B.45. 



15 







lABu; B.4,5 




1 Attribute 


Senc^^r 


Receivei;- 




"position" 


Integer 




M 


"procedure" 


Procedure 




M 


" resource" 


Resource 





20 S.3,fi User-defin ed Fraip^ 

An example of this class is encoded using the primary 
palette in Table B.46. 



TABLE a,/Ig 
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5 





Attribute 


Sendey 




M 


"position" 


Integer 




1 




"responder" 


Object 


Agent* 


2 


"stack" 


stack [Object] ! 


Cleared 


3 


"variables" 


List [Object] ! 


Cleared 



The agent of whose frames attribute this frame is an item. 
5.Xu2 While PT-am>. 

An example of this, class is encoded using the primary 
palette in Table B.47. 



10 



15 







t 




Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 




|M 


"precondition" 


Executed 




ll 


"is Pr econdi t i on " 


true 


false 1 
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APPENDIX C 

Copyright « General Magic, Inc. 1992, 1993. All Rights 
Reserved 

The following table of contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 



Table of rnr^t^^T^i-o 

1 . INTRODUCTION 
Overview 

10 Organization 
References 

2. INTERFACE CONCEPTS 

2.1 Telenarae 

2.2 Network 
15 2.3 Engine 

2.4 Platform 

2 . 5 Region 
2 . S Outpost 
2 . 7 Domain 

20 2.8 Transfer 
35 2.9 Transfer Unit 

2.10 Destination 

2.11 Transfer Group 

2 . 12 Way 

40 

25 2.13 Means 

2 . 14 Reservation 

2.15 Rank 

45 3. COMMUNICATION CLASSES 

3 . 1 Reservation 

30 3.2 Reservable Means 

3.3 PSTN Means 

3.4 Existing Connection Means 
4. INTERFACE IN TELESCRIPT 
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4.1 


Engine 


4.2 


Platform 


4,3 


Destination 


4.4 


Failure 


5 5. 


ROUTING 




Routing Algorithm 


6, 


INTERFACE IN C++ 




Interface description 




Tasks 


10 


CI Class 


7. 


TELESCRIPT INTERFACE OBJECTS 


7,1 


Interface Conventions 


7.2 


TsCharacter 


7.3 


TsDestination 


15 7.4 


TsDestinationList 


7.5 


TsExi s t ingConnec t i onMe ans 


7.6 


Ts Integer 


7.7 


TsIntegerList 


7.8 


TsMeans 


20 7.9 


TsObj Specifier 


7.10 


TsOctet 


7.11 


TsOctets 


7.12 


TsPSTNMeans 


7.13 


TsReservableMeans 


25 7.14 


TsReservation 


7,15 


TsString 


7.16 


TsTeleaddress 


7.17 


TsTelename 


7.18 


TsTelenumber 


30 7.19 


TsWay 



1. INTRODUCTTOy 
OverviQw 

This appendix defines the "communication services 
that a Telescript engine can obtain from the platform 
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which it runs. Two engines employ these services to 
transfer the representation of an "agent" from a place in 
one engine to a place in the other, as required by 
Telescript's "go" and "send" operations. 
5 This appendix has two main parts. First, this 

appendix describes the communication services that a 
Telescript engine requires in an abstract way, using 
Teiescript to describe the interface between engine and 
platform. Second, this appendix documents a C++ 
10 "application programming interface" (API) which provides 
those services. 

QrqayiUatj.9q 

This appendix is divided into seven sections. 
Section 1 is this introduction. Section 2 describes the 

15 basic concepts of the interface* Section 3 describes some 
additional Telescript classes. Section 4 specifies the 
interface in Telescript. Section 5 describes a transfer 
in more detail* Section 6 describes a C++ API which 
implements the interface. Section 7 describes C++ 

20 representations of Telescript classes which are used in 
the API. 

References 

This appendix relies upon Appendix A of this 
disclosure. 

25 2^ INTERFACE CONCEPTS 

This section of this appendix describes the basic 
concepts of Telescript communication and communication 
interfaces. Many of the objects described here have 
direct representations in the Telescript instruction set 
30 or in the communication interface of the engine. 

2^ Telename 
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Telescript supports the movement of objects between 
places and specifically between engines. Every place in 
the Telescript universe is assigned a distinct "telename". 
Telenames have two attributes, an "authority" and an 
"identity". 

Telescript supports telenames, whether assigned or 
otherwise. An "assigned telename", associated with an 
object by a Telescript engine, always contains both an 
authority and an identity. A telename which is not 
"assigned" purports to identify one or more Telescript 
objects. A telename which is not "assigned" can have its 
identity attribute omitted, in which case the telename can 
actually identify several objects. 



1^ Network 

15 A Telescript -network- comprises one or more regions. 

25 The network may not fully interconnect all of its regions 

and "point-to-point" transfer of information may not be 
possible between any two of them. Regions are 
interconnected, however, to the extent that the network 
20 can provide "store -and -forward" transfer of information 
between any two of them. 



1^ Engine 

An -engine- is a computer process that implements the 
abstractions of the Telescript instruction set. An engine 
25 does this, in part, by communicating with other engines. 
An engine is denoted by an assigned telename. 



1^ Platform 

^ A "platform" is a collection of hardware and software 

that supports one or more engines. A platform enables 
30 engines to communicate with other engines on the same 
platform and on other platforms to which the platform is 
connected. 
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2 . 5 Region 

A "region" comprises the engines and supporting 
platforms operated by an individual or organization. 

A region fully interconnects the platforms the region 
5 contains. Thus the region enables the point-to-point 
transfer of information between any two of these 
platforms. Each region contains one or more platforms 
that provide access to and egress from the region. It is 
by means of these platforms that regions are 
10 interconnected to form a network, A region is denoted by 
a telename in which the identity attribute is omitted. 

A region can have an outpost in another region. An 
"outpost" is a place in a region which routes traffic from 
15 that region to the outpost's region. 

P<?Tnflin 

A "domain" is a region, together with all of its 
outposts in other regions. 

2^ Transfer 

20 A "transfer" is the conveyance of a transfer unit 

from one engine, the "source engine", to another, the 

"destination engine", 

A transfer unit specifies a "destination" which can 

be used to route the transfer. Additionally, a way can be 
25 provided which can influence the route and "transport" 

used for the transfer, 

2^ Transfer Uni^ 

A "transfer unit" is conveyed between engines in a 
transfer. A transfer unit consists of an octet string, 
30 and a destination. These are the only data items that are 
delivered end to end between engines. Additional data is 
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involved in specifying the transfer to the "originating 
platform" and in receiving a transfer at the destination. 

A "destination" describes the ultimate destination of 
5 a transfer unit. 

Transfer Group 

The Telescript "send" operation, which is described 
in Appendix A, can result in the same octet string being 
delivered to several destinations. A "transfer group" is 

10 a collection of transfer units and their associated 

destinations, together with one copy of the octet string 
being conveyed, 

A transfer group logically represents its component 
transfer units. A platform can break up a single transfer 

15 group into multiple smaller transfer groups and/or single 
transfer units. 



A "way" specifies a region or engine, a means of 
communicating with the region or engine, and 
20 "authentication information" used to do so. 

A transfer out of an engine can specify a way, i.e, 
the "way out", which defines communication requirements 
for the transfer. Incoming transfers provide engines with 
a way, i.e., the "way back", which can be used as the way 
25 out in sxibsequent transfers towards the original source. 

1^11 Msans 

A "means" specifies a type of transport to be used 
for a transfer, e.g., wireline or wireless network. A 
means contains transport specific data such as a "quality 
30 of service" parameter or the telephone number for a "PSTN" 
connection. 
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A "reservable means" specifies a type of transport 
for which a reservation is honored. 

2^01 Reservation 

A "reservation" is a request that a connection 
5 established by a platform as the result of a transfer be 
maintained for some period of time. Reservations are 
hints to allow a connection to be used for multiple 
transfers. 

A reservation has meaning only when a transfer 
10 specifies a way with a reservable means. 

2.15 Rank 

Some transfers may be considered "privileged" , A 
"rank" is an indication of privilege. It is an integer, 
the value zero meaning unprivileged. The meaning ot non- 
15 zero values is source region specific. In inter-region 
transfers, a rank can be regarded as a hint which can be 
changed or ignored. 

1^ Communication Classes 

This section defines additional Telescript classes 
20 which are not present in Appendix A of this disclosure. 

1^ Reservation 
Ob j ect 

• Reservation 

25 Reservation. 

interface 0 ^ 

Public Inataqq ^ Attribu^ ^l=^.c^ 
Integer; 
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An identifier for a reservation created by a 
platform. 

3.2 Reservable Means 
Object 
5 • Means 

• • Reservable M^;^^» 

Class 

ReservableMeana : 

abstract interface (Means) « (-..); 

10 Public Instance At tributes 
reservation! 
Reservation; 

An identifier for a reservation created by a 
platform. 

15 3^ PgTN Means 
Object 

• Means 

• • Reservable Means 

• • • PSTN Means 

20 

PSTNMeang r 

interface (ReservableMeans) - (,.,); 

Public Inatan^^ AttributAA 
telephoneNumtp^^* 
25 Telenumber; 

The telephone number to be used for this trip. 
3 t 4 Existin g Connection Meap g 
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Object 

• Means 

• • Reservable Means 

• • • Existing Connection M^^^^ 

5 Class 

EjcistingConnectionNfic^^p^ . 

interface (ReservableMeans) = (,,.); 



IS Public Instance Atti-i>^iih^o 

connect ionlD; 
10 Octets; 



10 



20 
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SO 



A identifier which a platform can use to identify a 
connection. 



25 ^ INTERFACE IN TELR«grPTtyr 

In this section, the interface between an engine and 
15 its platform is specified as if both were Telescript 
objects, which they are not. It is intended that this 
definition be considered generic, i.e. independent of 
specific programming languages used to implement engines 
and platforms. 

The following Telescript class definitions are used 
in this interface. See Appendix A and Section 3 of this 
Appendix for their definitions: 



20 



Integer 
List 

25 OctetStrinc^ 
Tgisnamg 
TeleaddrPiflq 
Way 

Reservation 
30 4^ E^qi,n^ 
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Object 

• Engine 

Ensing: 

5 interface ( ) » (...); 



Public Instance Qperati^nff 

Cgflnsferln: 

15 op ( 

octets: OctetString; 
10 destinations: List [Destination] ; 

rank: Integer; 
way: Way; 

timeAdjust : Integer) 
throws TransferlnFailed; 



15 Delivers one or more transfer units associated with a 

single transfer group to the engine. The transfer units 
are represented by the octets, destinations and rank. The 
way back (argument "way") contains the telename of the 
engine which performed operation " trans f e rOut " , The way 

20 back can provide an existing connection means which can be 
used to make a return trip. 

Argument "timeAdjust" is the number of seconds by 
which the clock of the source platform trails the clock of 
the destination platform. The responder can use this 

25 information to adjust certain times that were generated 
relative to the source engine's clock. 

The "TransferlnFailed" exception is thrown if the 
engine is unable to receive the transfer units. 

30 op ( 

failure: Failure; 
octets: OctetString; 
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destinations: List [Destination]; 
rank: Integer; 
way: Way; 

timeAdjust: Integer) 
5 throws TransferFailedFailed; 

Delivers one or more failed transfer units associated 
with a single transfer group to the engine. The 
15 parameters for this operation are identical to those of 

operation "transferin" with the addition of the reason for 
10 the failure (argument "failure") . 

It is possible that a " trans ferFailed" operation can 
20 happen before a "transf erOutComplete" has been received at 

the source engine for the transfer group. 

If failure is "invalidMeans" , the responder will be 
15 the source engine if possible. 
^ An exception is thrown if the responder is unable to 

receive the failed transfer units 
("TransferFailedFailed") . 

30 

tran3ferQutFai,1,^r^- 
20 op { 

reason: Failure; 
35 groupiD: Integer; 

failures: List [Integer] | Nil) 
throws UnJcnownTransferGroup, UnknownTransf erUnit ; 

40 25 One or more transfer units in the transfer group 

(argument "groupiD") has failed. The cause of the failure 
is given in argument "reason". The particular units that 
have failed are identified by a list (argument "failures") 

^ of integer indices into the original list of destinations 

30 given at performance of operation transferOut. List 

indices begin at one, which identifies the first unit in 
the transfer group. 
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If a list is not provided, i.e, if the value of 
argument "failures", is nil, every transfer in the group 
has failed. This is identical to a list which enumerates 
all the units in the original group. 
5 An exception is thrown if the responder did not 

previously perform a " trans ferOut" operation denoted by 
argument "groupID" ( "UnknownTransferGroup" ) , or one of the 
items of argument "failures" is not a valid index into the 
destination list for this transfer group 
10 CUnknownTransferUnit ") . 

transf erOutComnlfitA . 

op (groupID: Integer; serialNumber : Integer) 
throws UnknownTranjsferGroup; 

Indicates that the "transferOut " operation associated 
15 with a particular transfer group (argument "grouplD") has 
been completed. In particular there can be no further 
"transferOutFailed" operations for this group. Any 
resources associated with the transfer units in this group 
may be released. 
20 An exception is thrown if the responder did not 

previously perform a transferOut operation denoted by 
argument "groupID" ( "UnknownTransferGroup") . 

Platform 
Object 
25 • Pla££s™ 

Class 

interface (}-{...}; 



Construetior] 

30 irnitifllizft: 

^ op {engine: Telename) ; 
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Initializes the responder for use by the named engine 
(argument "engine") . 

Public Instance Operations 

5 op (octets: OctetString; 

destinations; List {Destination]; 
rank: Integer; 
way: Way | Nil; 
desiredDuration: Integer; 
10 maximumDuration: Integer; 

groupID: Integer) 
throws InvalidDestination, InvalidWay; 

Requests delivery of a transfer group, which is 
defined by arguments "octets", "destinations", and "rank", 

15 to one or more destination engines. The group is 

identified by the group id (argument "groupID") . This 
operation results in one of operations "transf erin" , 
"transferOutFailed" or "transferFailed" subsequently 
referencing each of the transfer units that make up this 

20 group. 

The rank (argument "rank") specifies whether this 
transfer is privileged. 

If argument "way" is non-not a nil, it will be used 
to route the transfer. 

25 The desired duration of the transfer is specified in 

seconds (argument "desiredDuration"). This is the maximum 
elapsed time desired for the transfer. A value of zero 
for the desired duration indicates that no desired 
duration is associated with this transfer. 

30 The maximum allowed duration for the transfer is 

specified in seconds (argument "maximumDuration") . This 
is the maximum time allowed for the transfer. If 
operation "transf erOutComplete" has not happened this many 
seconds after the " transf erOut" operation, then the effect 
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is the same as though a "failTransfer" operation is 
performed for this group. A value of zero for the maximum 
duration indicates that no maximum duration is associated 
with this transfer. 
5 An exception is thrown if the destination list is 

invalid ( " invalidDestination" ) or if argument "way" is 
supplied but has no non-nil attributes ("invalidWay") , 

failTranefer: 
op (groupiD: Integer! 
10 throws UnknownTransf erGroup; 

Requests that all. pending transfer units in the 
transfer group identified by the group id (argument 
"groupID") be failed. 

It is possible that not all transfer units in a - 
15 transfer group can be failed. Transfer units failed as a 
result of this operation will cause one or more 
"transferOutFailed" operations followed by a 
" transf erComplete" . 

An exception is thrown if the group id was not used 
20 in a previous " trans ferOut" (operation 
"UnJcnownTransferGroup") . 

makeReserval^iQnr 

op (duration: Integer) Reservation 
throws CannotReserve; 

25 Returns a new reservation of duration (argument 

"duration") seconds. The reservation becomes active when 
the reservation is used in a reservable means for a 
subsequent "transferOut " operation. 

Once a reservation expires, the reservation is no 

30 longer valid and transfers will fail if they attempt to 
use the reservation. 
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Reservations should be canceled with the 
"resetReservation" operation when they are no longer 
required. Platforms can impose maucimum lifetimes on 
unused reservations. 
5 The "CannotReserve" exception is thrown if the 

responder is unable to provide a reservation. 

resetReservation ! 

op (reservation: Reservation, duration: Integer) 
throws UnknownReservation, InvalidReservation; 

10 The duration of an existing reservation (argument 

"reservation") is changed to duration seconds. If the 
reservation is active when this operation is invoked, the 
effect is the same as if a "transf erOut- operation had 
just been done with a reservation of the new duration. 

15 Setting the duration to zero cancels a reservation. 

A canceled reservation is no longer valid. 

An exception is thrown if reservation was not 
obtained with a prior "makeReservation" operation 
CunknownReservation"), or if the reservation is no longer 

20 valid ("InvalidReservation"). 

LlA Destination 
Object 

• Destination 
Class 

25 Eastinatisn: 

interface ()=(...); 

Construction 

initialize; 
op { 

*0 name: Telename | Nil; 

address: Teleaddress j Nil; 
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data: OctetString [ Nil) ; 

Sets the responder's native attributes to the like- 
named arguments (arguments "name", "address", and "data"). 

If all the attributes of a destination are nils, the 
5 destination is invalid. 

Private Instance Attributeg 

Teleaddress | Nil; 

20 The address of the destination. 

10 data : 

OctetString I Nil; 
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Engine specific data associated with a transfer unit. 
name ; 

Telename | Nil; 
15 The name of the destination. 

1^ Failure 
Ob j ect 

• Failure 

Clasq 
20 EaiiliJlft: 

interface { ) « (...); 

Private Inst^anr^ e Attrihyh^c 
r^aggg: 
Integer;' 
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The reason for the failure of a transfer. The reason 
is represented as an integer enumeration shown in table 
C.l. 



imp <;,l 



10 



15 



5 

1 


1 


invalidDestination 


**** *-wsHt.inauion was 
provided. 


J 


2 


invalidWay 


An invalid wav uao 
provided. 


3 


invalidMeans 


"** ***v<*Axwi meeiris was 

provided. 




4 


invalidReservation 


iiivaixa reservation was 
provided. 




5 


noDe s t i na t i ons 


uesiumacions were 
specified. 




6 


maximumDurationExceeded 


The maximum duration has 
passed. 




7 


transfersFailed 


failTransfers was called. 




noLocalResources 


The platform failed to get 
some resource. 






destinationUnreachable 


A transfer unit was 
undeliverable. 




10 


transferlnFailed 


transform failed at the 
remote engine . 




11 


securityViolation 


There was an authentication 
failure. 




12 ] 


poesibleDuplicate j 


^ay have been delivered. 

— = — ^ — . 
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A platform can provide additional failure types. 

5 

5^ ROUTING 

The "transferOut" operation of a transfer unit 
typically results in the " transf erln" operation of the 
5 same unit at a different engine. If the transfer fails at 
the source platform, the transfer unit is failed with a 
"transferOutFailed« operation at the source engine. If 
15 transfer unit is successfully transferred from the 

source platform but does not participate in a successful 
10 "transferln" op" - operation at the destination engine, it 
is failed to an engine with "transf erFailed" op°, 
20 The "transferOut" op" of a transfer group is logically 

equivalent to N " transferOut" op'^s of the component 
transfer units. The value of rank, desired and maximum 
15 durations and the way are identical for all the transfers. 
The list of destinations can imply op" "transferin" occurs 
at more than one destination engine. 

Typically, a platform will examine the list of 
^ destinations in a group and attempt to deliver the units 

20 with the minimum number of "transferin" op'*s at destination 
engines. This implies that transfer units destined for 
the same engine will be transported and delivered as a 
35 group. 

Routpinq A^gpyi^^hm 
^5 If a way is provided in a performance of 

^ "transferOut" op\ the platform uses it to route the 

transfer. If a way is not provided, the platform must 
determine the destination engine. The steps for 
^ determining the destination engine based on the name and 

30 address associated with a transfer unit are: 

<start> 
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if the name is present but the address is not 

<use the name> 
if the address is present but the name is not 
i£ the provider is the current region 

find the corresponding name or <fail> 
set the name attribute of destination to 



name 



<start> 

t5 10 <use the address> 

iJ[ both the- name and address are present 
^ if the provider is the current region 

<use the name> 

else 

15 <use the address> 



<use the name>; 

if the authority is the current region 
if the identity is present 

determine the destination engine 
20 from the identity or <fail> 

else 

determine the destination engine 
from the location or <fail> 

else 

25 route to the engine that contains the 

outpost of authority or <fail> 

<use the address>: 

if the provider is known 

route to the engine containing 
^0 the outpost of the provider 

far each of the providers in the routing advice 
if it is the current region 
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remove it from the routing advice 

else 

if the provider is knovm 

route to the engine containing 
^ the outpost of provider 

if there is still no route then <fail> 

<fail>: 

if the provider is the current region 
fail the transfer 

10 siaa 

if there is a default engine 

route to it 
else 

fail the transfer 

25 15 5^ INTERFACE TN Cf^ 

This section describes a C++ implementation of the 
engine -platform interface. This interface is derived from 
the Telescript specification of the interface in Section 
4. 

20 



10 



15 



20 



30 



By necessity, the interface presented here reflects 
aspects of the current Telescript engine's implementation. 
35 In particular the C++ API includes operations on the 

engine which do not appear in the generic interface. 



40 
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Interface descriot^i^^ 

The engine object is represented by the C++ class 
"CI". Operations on the engine object are provided as 
member functions of CI. 
^ The platform object is represented by a subclass of 

CI. The provider of a platform subclasses of CI and 
30 implements virtual functions of CI which represent the 
platform operations. 

The Telescript objects which appear as parameters to 
the operations on both engine and platform are represented 
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by a number of C++ classes which implement limited 
representations of Telescript objects. For example there, 
is a "Tslnteger" class which represents a Telescript 
"Integer" wherever "Tslnteger" appears in the API. A 
5 complete description of these Telescript Interface Objects 
appears in the next section of this appendix. 

Exceptions, which are specified in the Telescript 
representation of the interface, are implemented in the 
API as an enumerated type which is returned from all 
10 operations on both engine and platform. 

The storage for the data elements passed between 
engine and platform is owned by the caller of an 
operation. The storage can be reclaimed when an operation 
is complete. The only exception to this is the 
15 "transferOut "operation. The engine does not reclaim the 
elements of a transfer out until the corresponding 
"transferOutComplete" operation has been performed. 



The engine is implemented as multiple co-operating 
20 tasks running as separate threads with a non-preemptive 
scheduler. An instance of the CI class is run as a thread 
in the engine, A subclass of the CI class provides a 
function, "mainO", which is called once and should only 
return when additional operations on the platform are no 
25 longer supported. 

"mainO" is expected to yield to the engine scheduler 
when there are no pending "transferin" operations, 
"mainO" does this by calling "waitO", "waitO" takes 
an argument which is the number of milliseconds that the 
3 0 CI is willing to yield for. Typically the engine will not 
reschedule the CI's task until at least that amount of 
time has passed. An argument of zero to -waitO" implies 
that the CI is yielding but would like to be rescheduled 
as soon as possible by the engine scheduler. 
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An argument of -l to "waitO" has the meaning that 
the CI wishes to block indefinitely. m this case, the CI 
is expected to call "satisfyO" on the engine when the CI 
wishes to be rescheduled. "satisfyO- will cause a thread 
S blocked in wait to resume execution as soon as the engine 
schedules the thread. This latter scheme would be 
appropriate for a CI implementation which was delivered an 
asynchronous event when there were new communications 
requests. 

10 on some operating systems, a CI implementation may 

wish to yield to the engine scheduler and be rescheduled 
when a file descriptor becomes ready. The "waitfd" 
operation specifies a file descriptor to wait on and may 
be used in conjunction with "waitO" to select on multiple 
15 file descriptors with a timeout. 

Performances of op" "transferOuf are executed in the 
thread of the calling Telescript processes and not in the 
thread of the CI task. 

Operations on both engine and platform must execute 
20 relatively quickly, if necessary by queuing work to be 
scheduled later. Both engine and platform should not 
block for extended periods of time. 

In extreme situations, the volume of "transf erOut" 
operations may overwhelm the buffering provided by a CI, 
25 m this situation, the CI can call "stopO" which will 
have the effect of preventing all further calls to op- 

transf erOut". A subsequent call to "start ()" will resume 
output, possibly rescheduling engine tasks that had to be 
halted as a result of the blockage. 

30 CI Cla.«»fl 

Conatruet-^nn 
SLl 

CI (TsTelename "name) ; 
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Constructs a new CI object. "name" is the telename 
of the engine which will use this CI. 

virtual -CI () 
5 Shuts down and destroys this CI. 

maim 

virtual long mainO » O; 

The main loop of a CI. This is called some time 
after construction. The CI should yield to. the engine, 
10 e.g. with "wait 0% during the execution of this function. 

Engine Operations 

Tsstatus transferin (TsOctets *bagOfBits, 

TsDestinationList *destList, 

unsigned int rank, 
TsWay *wayBack, 
int timeAdjust) ; 

Transfers one or more transfer units into the engine. 



463 



EP0634 719A2 



t;ransfeirFai,Xed; 
5 TsStatus transferPailed (TsFailure failure, 

TsOctets *bagOfBits, 

5 TsDestinationliist *destList, 
10 unsigned int rank, 

TsWay ♦wayBack, int 

timeAdjust) ; 



IS 



Transfers one or more failed transfer units into the 
10 engine. 

20 traneferOutPail^^- 

TsStatus transferOutFailed {TsFailure failure, 

unsigned int groupid, 
TsIntegerList 

25 15 *list) ; 

Identifies one or more transfer units which have 
failed a previous performance of op» "transf erOut" from 
this engine. 



30 



tranaf erOutc^mp^<l^o . 
35 20 TsStatus transferOutComplete (unsigned int groupid, 

unsigned int 

transferSN) ; 
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Indicates that the transfer of a transfer group 
(argument "groupid") has completed. The storage 
25 associated with all the transfer units in this group can 
be reclaimed. 

Platform QpAyg^t^r^p» 
tranaferp^^i^; 

virtual TsStatus transferOut (TsOctets *bagOfBits, 

30 
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25 



35 
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TsDestinationList *de3tLisC, 
unsigned int rank, 
TsWay *wayOut, 

unsigned int desiredDuration, 
5 unsigned int maximumDuration, 

unsigned int groupid) • 0; 

Transfer the transfer units in this transfer group to 
their respective destinations {argument "destList"). 

10 virtual TsStatus failTransfer (unsigned int groupid) 

- 0; 

Fail all the transfer units associated with the 
transfer group (argument "groupid"). 



makeReaeiryatinn; 
15 virtual TsStatus makeReservation {unsigned int 

duration, TsReservation 
30 *reservation) = 0; 

Request a new reservation (argument "reservation") 
with the specified duration (argument "duration"). 



20 resetReservat^iQi^. 

virtual TsStatus resetReservation (TsReservation 
reservation, unsigned int duration) 



0; 



Reset the duration of reservation to the new duration 
25 (argument "duration"). A duration of zero has the effect 
of canceling the reservation. 



Task Qngral;i,o||^ 

50 waiLi 
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void wait (long msec) ; 

Yields the current engine thread for "msec" 
milliseconds. The function will return when this thread 
is rescheduled. If argument "msec" is zero, the thread 
5 will be rescheduled as soon as the engine scheduling 
policy allows. If argument "msec" is -1 this call to 
"waitO" will not return until "satisfy {)'• (see below) is 
called or a file descriptor specified with "waitfdO" 
becomes ready. 

void satisfy () ; 

Causes the CI thread to be rescheduled if the CI 
thread is blocked in a "waitO" call. 



15 void waitfd (int fd, short mask) ; 

Specifies that subsequent "waitO" calls will return 
if the file descriptor "fd" becomes ready for either 
reading or writing as specified by "mask", "mask" is a 
bitmask constructed by OR-ing the values. "PObLIN" and 
20 "POLLOOT" which select for the file descriptor being 

readable and writable respectively. A "mask" of zero has 
the meaning that this file descriptor should no longer 
affect the operation of "waitO". 

waitreaulh- 
25 short waitresult (int f d) ; 

Returns a bitmask which can be used to test whether 
the file descriptor "fd" may have become ready during the 
previous "waitO" call. The result is a bitmask with the 
bits "POLLIN- and "POLLOUT" set if they were specified in 
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"waitfdO" and the file descriptor became ready for read 
or write respectively. 

stop: 

void stop () ; 



5 Causes the engine to throttle all "transferOut " op"s 

for this CI. No further transfers will be requested of 
,5 this CI, which may cause Telescript agents executing op" 

"go" or "send" to block. The CI should only invoke this 
operation if the CI would loose data by queuing further 
10 transfers. 



a tart: 

void start (); 

Informs the engine that it should no longer throttle 



op°s. 



30 15 7^ TELESCRIPT INTERFArR np.Ti:;r>y<; 

To enable communication with external systems, e.g. 
other Telescript engines or non-Telescript-based 
communicating systems, a Telescript engine must rely on 
communications services provided by a platform or 
20 operating system underlying the Telescript engine itself. 
To gain access to these services, the Telescript engine 
must support a mechanism to allow information to flow into 
and out of the Telescript abstraction. Specifically, to 
allow conversion between key Telescript objects and 
25 corresponding representations of these objects that are 
^ palatable to the underlying communication services. 

The Telescript Engine Interface Classes provide an 
abstract definition for a set of C++ classes that fulfill 
this need. The definition provided is abstract in that 
30 the C++ classes are not fully defined, but rather are 
described in terms of the Telescript engine's minimum 
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requirements on their functionality. Complete freedom is 
left to the implementor of these classes as to their 
internal mechanisms and their relationship with the 
underlying communication services. 



5 7^ Interface Convent: inng 

An implementation of the Telescript Engine Interface 
Classes must adhere to a set of conventions regarding the 
,5 use of data items which pass across the class interfaces. 

These conventions are expressed in terms of rules of 
10 ownership, wherein ownership^ is defined as the right to 
modify and the responsibility to destroy a given piece of 
20 data. 

Unless otherwise stated, an implementation of the 
Telescript Engine Interface Classes must adhere to the 
15 following interface conventions: 

• For all functions that accept reference or pointer 
arguments, ownership of the referenced or pointed to 
data passes from the caller to the object called, 
such that the object has the right to modify the data 

20 and the responsibility to destroy the data at the 

appropriate time. 

• For all fxmctions that return reference or pointer 
values, ownership of the referenced or pointed to 
data is retained by the called object. However, the 

25 object guarantees that, until the next call to a 

function that can modify the object, the data 
referenced/pointed at will not change. 

• When destroyed, an object will destroy all data for 
which is has ownership. 



30 7^ TgChayacCffr 

The "TsCharacter" type definition provides a limited 
C++ representation of the Telescript Character class, as 
defined in Appendix A of this disclosure. 
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An implementation of the "TsCharacter" type is 
required to be able to contain all ASCII characters. This 
is a minimum requirement. Preferably, an implementation 
of the "TsCharacter- type can contain all Unicode 
5 characters . 



2^ TsDeatinatinn 

The "TsDestination" class provides a C++ 
representation of the Telescript Destination class, as 
defined in Section 4 of this Appendix. An implementation 
10 of the "TsDestination- class shall provide, at a minimum, 
the following functionality, 
class TsDestination 

{ 

public: 

15 TsDestination (TsTeleaddress ♦ teleaddress, 

25 TsTelename * telename, 

TsOctets * data) ; 



-TsTeleaddress C) ; 

const TsTeleaddress * getTeleaddress () const; 
20 const TsTelename * getTelename {) const; 

const TsOctets * getData {) const; 

}; 



Construction 
^ TsDeatinatioT^. 

25 TsDestination (TsTeleaddress * teleaddress, 

TsTelename ♦ telename, 
^ TsOctets ♦ data) 

Constructs a new "TsDestination" object. 

50 tgl^flddresa 
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Either a pointer to a "TsTeleaddreas" object that is 
to form the teleaddresa value of the new "TsDestination- 
object, or the NULL pointer if the destination object is 
to contain no teleaddress value. 

5 telename 

Either a pointer to a "TsTelename- object that is to 
form the telename value of the new -TsDestination" object 
or the NULL pointer if the destination object is to 
contain no telename value. 

10 data 

Either a pointer to a "TsOctets" object that is to 
form the destination data value of the new -TsDestination- 
object, or the NULL pointer if the destination object is 
to contain no destination data value. 

15 Deatrucfcign 

-^T3Deatina^^9n; 

-TsDestination () 

Destrdys the "TsDestination" object. The 
"TsDestination- object and all data for which the object 
20 has ownership responsibility are destroyed. 



Data Ace^na 

aetTftl^a^^ytto^. 

^ const TsTeleaddress • getTeleaddress () const 

Returns either a pointer to the teleaddress value of 
25 the "TsDestination" object, or the NULL pointer if the 
destination object contains no teleaddress value. 

const TsTelename * getTelename () const 
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Returns either a pointer to the telename value of the 
"TsDestination" object, or the NULL pointer if the 
destination object contains no telename value. 

qgppati^^T 

const TsOctets * getData () const 

Returns either a pointer to the destination data 
value of the "TsDestination" object, or the NULL pointer 
if the destination object contains no destination data 
value - 



10 7^ TsDestinationLigt 

The "TsDestinationList- class provides a C++ 
representation of a Telescript class "List" as defined in 
Appendix A of this disclosure, constrained to contain 
objects of the class "Destination". An implementation of 
15 the "TsDestinationList" class shall provide, at a minimum, 
the following functionality, 
class TsDestinationList 

{ 

public: 

20 TsDestinationList (); 

35 -TsDestinationList (); 

const TsDestination * nextDestination () ; 
void reset ( ) ; 

size^t destinationCount () const; 



void appendDestination (TsDestination * 
destination) ; 

}; 



Construction 
50 TgPestinationList r 

30 TsDestinationList () 
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Constructs an empty "TsDestinationList" object. 

Destruction 

-TsDestination-Liat : 
-TsDestinationList () 

5 Destroys a "TsDestinationList" object. The 

"TsDestinationList" object and all data for which the 
object has ovmership responsibility are destroyed. 

Data Access 

appendPestination; 
10 void appendDestination (TsDestination * destination) 



Appends a single destination, in the form of a 
"TsDestination" object to the list of destinations 
25 contained within the "TsDestinationList" object. 

degtinatjign 

IS A pointer to a "TsDestination" object conveying the 

destination to be appended to the list of destinations 
within the TsDestinationList object. 



nextPestination; 

const TsDestination* nextDestination () 



20 



Returns either a pointer to a destination, in the 
form of a "TsDestination" object, or the NULL pointer: 
Over multiple invocations, the "nextDestination () " 
fimction returns the set of destinations contained within 
the "TsDestinationList" object in the order of their 
^ 25 containment. Subsequent to return of the last destination 
and until the next invocation of the reset function, the 
"nextDestination 0 " function returns the NULL pointer. 

50 reset : 
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void reset () 

Causes the next invocation of the "nextDestination ( ) " 
function to return the first destination contained within 
the "TsDestinationList" object. 

5 destinationCount ; 

size_t destinationCount {) const 

Returns the number of destinations currently 
contained within the "TsDestinationList " object. 

JL^ TsExistinqConnectiQnMA;=^ng 
10 The "TsExistingConnectionMeans" class provides a C++ 

representation of the Telescript "ExistingConnectionMeans" 
class, as defined in Section 3 of this appendix. An 
implementation of the "TsExistingConnectionMeans" class 
shall provide, at a minimum, the following functionality. 
15 class TsExistingConnectionMeans : public 

TsReservableMeans 

{ 

public: 

TsExistingConnectionMeans 
^ (const TsReservation & reservation, 

TsOctets * connectionid) ; 
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-TsExistingConnectionMeans 0; 

const TsOctets * getConnectionId () const; 
}; 

25 PPT^st;rM<?t;4Qn 

TgExistino-Conng^rr ronMPar^^ > 

TsExistingConnectionMeans (const TsReservation & 
reservation, 

TsOctets * connectionid) 
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Constructs a new "TsExistingConnectionMeans" object. 



A reference to a "TsReeervation- object that is to 
form the reservation value of the "TsReservableMeans" 
5 super-class component of the new 
"TsExistingConnectionMeans" object . 

connect j,gnl4 

A pointer to a -TsOctets" object that is to form the 
connection identifier value of the new 
10 "TsExistingConnectionMeans" object. 



Deatructiqin^ 

r-TsExistina-gonn ^ctionMi^fl ng . 
25 -TsExistingConnectionMeans () 

Destroys the "TsExistingConnectionMeans- object. The 
15 "TsExistingConnectionMeans" object and all data for which 
the object has ownership responsibility are destroyed, 

Pat^ Acc^gg 

aetCQnnp>nt-ir^nM; 

const TsOctets * getConnectionId () const 



20 Returns a pointer to the connection identifier value 

^ contained within the "TsExistingConnectionMeans" object. 

li£ Tslnteaeip 

The "Tslnteger- type definition provides a limited 
4S C++ representation of the Telescript class "Integer". 

An implementation of the "Tslnteger- type shall be 
capable of holding values in the range -2147483648 to 
+2147483647 inclusive. 
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7.7 TsInteaerList 

The "TsIntegerList" class provides a C++ 
representation of a Telescript class "List", as defined in 
Appendix A of this disclosure, constrained to contain 
5 objects of the class "Integer". An implementation of the 
"TsIntegerList" class shall provide, at a minimum, the 
following functionality, 
class TsIntegerList 

{ 

10 public: 

TsIntegerList (),• 
-TsIntegerList (); 
const Tslnteger * nextlnteger () ; 
void reset ( ) ; 
15 size_t integerCount {) const; 

25 void appendlnteger (Tslnteger integer) ; 

}; 

Construction 
^ T3InteQerLia^^; 
20 TsIntegerList () 

^ Constructs a new "TsIntegerList" object. 

Subsequent to construction and until the first 
invocation of the "appendlnteger () " function, the newly 
created integer list object will be empty. 

40 

25 D^stru9t;i,on 

-TsInteaerLifl^; 
-TsIntegerList ( ) 

Destroys a "TsIntegerList" object. The 
"TsIntegerList" object and all data for which the object 
» 30 has ownership responsibility are destroyed. 
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appendlnteaer: 

void appendlnteger (Tslnteger integer) 

Appends a single integer, in the form of a 
"Tslnteger" object, to the list of integers contained 
5 within the TsIntegerList object. 

integer 

An integer value to be appended to the list of 
integers within the "TsIntegerList" object, 

next Integer I 
10 const Tslnteger * next Integer () 

Returns either a pointer to an integer, in the form 
of a Tslnteger object, or the NULL pointer. Over multiple 
invocations, the "nextlnteger () • function returns the set 
of integers contained within the "TsIntegerList" object in 
15 the order of their containment. Subsequent to return of 
the last integer and until the next invocation of the 
reset function, the "nextlnteger () " function returns the 
NULL pointer. 

reset : 
20 void reset () 

Causes the next invocation of the "nextlnteger () " 
function to return the first integer contained within the 
"TsIntegerList* object. 

integerCount : 
25 size_t integerCount () const 

Returns the number of integers currently contained 
within the "TsIntegerList" object. 



55 



476 



BNSDOCID; <EP 063471 9A2J_> 



EP0634 719A2 



1^ TsMg^ng 

The "TsMeans" class provides a C++ representation of 
the Telescript class "Means" as defined in Appendix A of 
this disclosure. An implementation of the "TsMeans" shall 
5 provide, at a minimum, the following functionality, 
class TsMeans 

{ 

public: 

typedef enum 
10 { 

TsMeansType_PSTN = 0, 

TsMeansType_ExistingConnection » 1 
20 } Type; 

virtual -TsMeans 0-0; 
15 Type type {) const; 

protected : 

TsMeans (Type type) ; 

}; 
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Constructipn 
20 TsMeans ; 

TsMeans (Type meansType) 

^ Constructs a new "TsMeans" object. 

meansTvpe 

An enumeration specifying the means type value of the 
40 25 new "TsMeans" object. 

Destruction 

-TgM^^pg ; 



50 



virtual -TsMeans () 

Destroys the "TsDestination" object. The 
30 "TsDestination" object and all data for which the object 
has ownership responsibility are destroyed. 
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Type type () const 

Returns the means type value of the "TsMeans" object. 



5 7^ TgQMgpggigiey 

The "TsObj Specifier" provides a C++ representation of 
a class of objects each of which denotes a protocol and 
distinguishes that protocol from other protocols. For 
example, a member of the class represented by 
10 "TsObjSpecifier" can be used to denote a specific way of 
providing security. An implementation of the 
"TsObj Specifier" class shall provide, at a minimum, the 
following functionality, 
class TsObj Specifier 
15 { 

public: 

TsObj specifier (Tslnteger objid, 

TsOctets * namingAuthority) ; 
-TsObj Specifier (); 
20 Tslnteger getObjId () const; 

35 const TsOctets * getNamingAuthority () const ; 

); 



Construction 

TsObi Specif i^y. 

25 TsObj Specifier (Tslnteger objid, TsOctets ♦ 

namingAuthority) 

Constructs a new TsObj Specifier object. 
obi Id 

An integer value that is to form the object 
30 identifier value of the new "TsObjSpecif ier" object. 
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Either a pointer to a "TsOctets" object that is to 
form the naming authority value of the new 
"TsObjSpecifier" object; or the NULL pointer, if the new 
5 "TsobjSpecifier" object is to contain no naming authority 



value , 
Destruction 

*-TsObj Specifier {) 



10 Destroys the "TsObjSpecifier" object. The 

-TsobjSpecifier- object and all data for which the object 
has ownership responsibility are destroyed. 



Data Arcesa 
25 aetObi Id ; 

15 Ts Integer get Ob j Id () const 



Returns the object identifier value contained within 
the -TsobjSpecifier" object. 



qetNamina- Author n^v. 
^ const TsOctets * getNamingAuthority () const 

20 Returns either a pointer to a -TsOctets" object 

conveying the naming authority value contained within the 
40 "TsobjSpecifier" object; or the NULL pointer, if the 

"TsobjSpecifier" object contains no naming authority 
value - 



25 7,1Q TsQctgt. 

The TsOctet type provides a C++ representation of the 
Telescript class "Octet" as defined in Appendix A of this 

^ i — — T 
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The "TsOctet" type shall be defined as a unsigned 

char . 

7^ TsQctet:g 

The "TsOctets" class provides a C++ representation of 
5 the Telescript class "Octets" as defined in Appendix A of 
this disclosure. An implementation of the "TsOctets" 
class shall provide^ at a minimum, the following 
functionality. 

class TsOctets 
10 { 

piiblic : 

20 enum CopyOwnership { makeCopy, ownCopy, 

borrowCopy ); TsOctets (size^t size) / 

TsOctets (size_t size, const TsOctet * data, 

CopyOwnership ownership « makeCopy) ; 
-TsOctets ();const TsOctet * nextSeg (int & 
segSize) ; void reset () ; 

size_t size () const ; 

30 

void appendSeg (si2e_t size, const TsOctet * 

20 data) ; 

}; 

$5 

Const rugt^i^r^ 

TsOctets; 

TsOctets "size^t size, TsOctet * data, CopyOwnership 
^ 25 ownership) 

constructs a "TsOctets" object from a single array of 
"TsOctet" objects. 



45 
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size 

The number of octets to be contained within the new 
30 "TsOctets" object. 
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data 

5 

A pointer to an array of octets, i.e., "TsOctet" 
objects, to be contained within the new "TsOctets" object. 
The number of elements in the array must be greater than 
5 or equal to the value of "size". 

N2t£: For the case where "size" is zero, a zero length 

array must be provided by the caller. 

15 ownership 

An enumeration specifying the method by which the 
10 array of octets is to be incorporated into the new 
«TsOctete" object. The possible values are: 

20 

"makeCopy": the data within the octet array must be 

incorporated into the new "TsOctets" object 
25 the construction of a separate physical 

^^^y- Subsequent to the construction, the 
caller retains complete ownership of the 
original octet array. 
30 When the ownership argument specified is 

"makeCopy", the octet array provided by the caller 
may be either statically, dynamically or 
automatically allocated. 



35 



40 



20 



25 



"ownCopy": The data within the octet array can, at the 

implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided octet array itself. Subsequent to 
the construction, the caller relinquishes 
45 ownership of the provided octet array to 

the new "TsOctets" object. 



30 

50 
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When the ownership argument specified is 
"ownCopy", the octet array provided by the caller 
must be dynamically allocated. 
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"borrowCopy": The data within the octet array can, at the 
implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided octet array itself. Subsequent to 
the construction of the "TsOctets" object 
and until its destruction, the caller loans 
the caller's ownership of the provided 
octet array to the new "TsOctets" object. 
For this duration, neither the caller nor 
the "TsOctets" object may modify or destroy 
the octet array. Upon destruction of the 
"TsOctets" object, complete ownership of 
the octet array passes back to the caller. 
^5 When the ownership argument specified is 

"borrowCopy", the octet array provided by the caller 
can be either statically, dynamically or 
automatically allocated. 

30 TQQg^^%^ ; 



10 



15 

10 



20 



25 



35 



40 



20 



25 



TsOctets (si2e_t eventualSize) ' 

Constructs an empty "TsOctets" object in preparation 
for the addition of data using the "appendSeg () " function, 
which is described below, 

eventualgl^^ 

The maximum number of octets to eventually be 
contained with the new "TsOctets" object. 



45 Destructi^^n 

-TsOctets 0 
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Destroys the "TsOctets" object. The "TsOctets" 
object and all data for which the object has ownership 
responsibility are destroyed. 

D^t;a Agcegs 
5 appendSeo ! 

void appendSeg {size_t size, 
TsOctet * data, 
CopyOwnership ownership) 

Appends an array of octets, i.e., "TsOctet" objects 
10 to Che set of octets already existing within the 
"TsOctets" object. 

HQtfi: The effect of invoking this function upon a 
"TsOctets" object created by means of a 
constructor other than the "TsOctets", i.e., by 
15 means of argument "eventual Size" of the 

constructor function above, size "eventualSize" 
constructor is implementation defined. 
Additionally, the effect of appending more data 
than that declared in the "eventualSize" 
parameter of the constructor is also 
implementation defined. 

aize 

The number of octets to be appended to the "TsOctets" 
ob j ect . 

25 dat^ 

A pointer to an array of octets, i.e. "TsOctet" 
objects, to be appended to the "TsOctets" object. The 
number of elements in the array must be greater than or 
equal to the value of "size". 
30 JSQ^z For the case where "size" is zero, a zero length 

array must be provided by the caller. 



20 
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ownership 

An enumeration specifying the method by which the 
array of octets is to be incorporated into the "TsOctets« 
object. The possible values and their corresponding 
5 meanings are the same as those described for the "TsOctets 
(3ize_t size, Tsoctet * data, CopyOwnership ownership)" 
function. 

nextSea ; 

const Tsoctet * nextSeg (ai2e_t t segSize) 

10 Returns either an array of octets and a size value or 

the NULL pointer. Over multiple invocations, the 
"nextSeg" function returns a collection of octet array 
segments which together, in order of appearance, convey 
the array of octets contained within the -TsOctets - 

15 object, subsequent to the return of the last such segment 
and until the next invocation of the -reset" function, the 
-nextSeg- function returns the mJLL pointer and leaves the 
value of the "segSize- parameter unchanged 
Ji2££: The total number of segments returned and size 

of each individual segment are implementation 
dependent . 

seosizt* 

A reference to an unsigned integer value to be 
updated with the size of the segment being returned. 

25 reset: 

void reset () 

causes the next invocation the "nextSeg" function to 
return the first segment of octets contained within the 
"TsOctets" object. 

^0 size: 
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size_t size () const 



Returns the total number of octets currently- 
contained within the "TsOctets" object. 

ZOZ TsPSTNMeans 

The "TsPSTNMeans" class provides a C++ representation 
of the Telescript class "PSTNMeans", as defined in Section 
3 of this appendix. An implementation of the 
"TsPSTNMeans" class shall provide, at a minimum, the 
following functionality. 

class TsPSTNMeans : public TsReservableMeans{ 
piiblic: 

TsPSTNMeans (const TsReservation & reservation, 

TsTelenumber * telenumber) ; 
-TsPSTNMeans () ; 

TsTelenumber * getTelenumber C) const- 

}; 



Construction 

TsPSTNMeanfl. 

TsPSTNMeans (const TsReservation & reservation, 
TsTelenumber * telenumber) 

Constructs a new "TsPSTNMeans" object. 

reservati^Ti 

A reference to a "TsReservation" object that is to 
form the reservation value of the "TsReservableMeans" 
super-class component of the new "TsPSTNMeans" object. 

cglenumbgr 

A pointer to a "TsTelenumber" object that is to form 
the telenumber value of the new "TsPSTNMeans" object. 

D^struCtiiOT 
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--TsPSTNMeans i 
-TsPSTNMeans 0 

Destroys the "TsPSTNMeans" object. The "TsPSTNMeans" 
object and all data for which the object has ownership 
5 responsibility are destroyed. 

Data Access 

ae t Telenumber ; 

const TsTelenumber * getXelenumber () const 

Returns a pointer to the telenumber value contained 
10 within the "TsPSTNMeans" object. 



2^ TsReaervableMe^n^ 

The "TsReservableMeans" class provides a C++ 
representation of the Telescript class "ReservableMeans" , 
as defined in Section 3 of this appendix. An 
15 implementation of the "TsReservableMeans" class shall 
provide, at a minimum, the following functionality, 
class TsReservableMeans : public TsMeans 
{ 

protected: 

^ TsReservableMeans (TsMeans :: Type type, 

const TsReservation & reservation) ; 
virtual -TsReservableMeans () / 
p\iblic: 

40 

TsReservation & getReservation {) const; 

25 }; 

45 C9n?tirvct;j,Qri 

TsRegervab1„^|W[^^T^°' 

TsReservableMeans (TsMeans :: Type type, 

const TsReservation & reservation) 



30 Constructs a new "TsReservableMeans" object. 
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An enumeration specifying the means type value of the 
"TsMeans" super- class component of the new 
"TsReservableMeans" object. 

5 reservation 

A reference to a "Ts Reservation" object conveying the 
reservation value to be contained within the new 
"TsReservableMeans" object. 

10 -TsReservable-Mganfi . 

virtual -TsReservableMeans {) 

Destroys the "TsReservableMeans" object. The 
"TsReservableMeans" object and all data for^ which the 
object has ownership responsibility are destroyed, 

15 Data Acces^ 

aetReservation; 

const TsReservation & getReservation () const 

Returns a reference to the reservation value 
contained within the "TsReservableMeans" object, 

20 7_J^ T3Reflervatiir.n 

The "TsReservation" class provides a C++ 
representation of the Telescript class "Reservation", as 
defined in Section 3 of this appendix. An implementation 
of the "TsReservation" class shall provide, at a minimum, 
25 the following functionality, 
class TsReservation 

{ 

public: 

TsReservation (Tslnteger id = 0) ; 
30 -TsReservation () ; 
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Tslnteger id 0 const; 

}; 

Construct ior^ 

TsReservatinn. 
5 TsReservation (Tslnteger id « 0) 

Constructs a new "TsReservation" object. 

A "Tslnteger" that is to form the reservation 
identifier value of the new "TsReservation" object. 

10 Destructinn 

-^TsReservatiQn; 
-TsReservation () 

Destroys the "TsReservation" object. The 
"TsReservation" object and all data for which the object 
IS has ownership responsibility are destroyed. 

Data Accegg 

Tslnteger id () const 

Returns the reservation identifier value of the 
20 "TsReservation" object. 



iOS TgStriM 

The TsString class provides a C++ representation of 
the Telescript class "String", as defined in Appendix A of 
45 this disclosure. An implementation of the "TsString" 

25 class shall provide, at a minimum, the following 
functionality. 



50 



Issus: This needs to be extended to support non- ASCII 
character sets. 
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class TsString 

{ 

public: 

TsString (const TsCharacter * string) ; 
-TsString ( ) ; 

const TsCharacter * getString () const; 
size^t size {) const; 

}; 



IS Construction 

10 Tigering; 

TsString (const TsCharacter * string) 
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Constructs a new "TsString" object, 



string 

2« A pointer to a "TsCharacter" array, terminated by a 

15 null character, conveying the string of characters to be 
contained within the new "TsString" object. 



Des^JTUgtioja 

-TsString: 
-TsString () 

20 Destroys the "TsString" object. The "TsString" 

object and all data for which the object has ownership 
responsibility are destroyed. 

Data Acg<>flfl 

getStrina; 

25 const TsCharacter * getString () const 

Returns a pointer to the string of characters 
contained within the "TsString" object. 

sisfij. 
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size^t size () const 

Returns the number of characters currently contained 
within the "TsString" object. 

2^ TsTeleaddresB 
5 The "TsTeleaddress" class provides a C++ 

representation of the Telescript class "Teleaddress" , as 
defined in Appendix A of this disclosure. An 
15 implementation of the "TsTeleaddress" class shall provide, 

at a minimum, the following functionality, 
10 class TsTeleaddress 

{ 

public: 

TsTeleaddress (TsOctets ♦ provider, 
TsString * location) ; 
25 15 -TsTeleaddress () ; 

const TsOctets * getProvider () const; 
const TsString ♦ getLocation () const; 
const TsOctets * nextRoutingAdvice () ; 
void reset ( ) ; 
2 0 int routingAdviceCount () const; 

35 void appendRoutingAdvice (TsOctets * advice) • 

}; 



20 



30 



40 



45 



50 



Conatructioq 

TsTeleaddress ; 

25 TsTeleaddress (TsOctets ♦ provider, TsString * 

location) 

Constructs a new "TsTeleaddress" object. 
Subsequent to construction, the list of routing 
advice elements contained within the newly created 
30 teleaddress object will be empty. 
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provider 

Either a pointer to a "TsOctets" object that ig to 
form the provider value of the new "TsTeleaddress" object, 
or the NULL pointer if . the new teleaddress object is to 
5 contain no provider value. 

loqatiQn 

Either a pointer to a "TsString" object that is to 
form the location value of the new "TsTele address" object, 
or the NULL pointer if the new teleaddress object is to 
10 contain no location value - 

-TsTeleaddreaa; 
-TsTeleaddress () 

Destroys the "TsTeleaddress" object. The 
15 "TsTeleaddress" object and all data for which the object 
has ownership responsibility are destroyed. 

appendRoutinQ-Adv;i,t7i7 - 

void appendRoutingAdvice (TsOctets * advice) 

20 ;^pends a single element of routing advice, in the 

form of a "TsOctets- object, to the list of routing advice 
contained within the "TsTeleaddress" object, 

A pointer to a "TsOctets" object conveying the 
25 routing advice element to be appended to the 
"TsTeleaddress" object's routing advice list. 



aetProvideip; 

^ const TsOctets * get Provider () const 
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Returns either a pointer to the provider value of the 
5 "TsTeleaddress" object, or the NULL pointer if the 

"TsTeleaddress" object contains no provider value. 

aetLocation: 
5 const TsStrmg * getLocation () const 

Returns either a pointer to the location value of the 
"TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no location value. 

nextRoutinaAdvicf* r 
20 10 const TsOctets ♦ nextRoutingAdvice () 

Returns either a pointer to an element of routing 
advice, in the form of a "TsOctets" object, or the NULL 
25 pointer. Over multiple invocations, the 

"nextRoutingAdvice () " function returns the set of routing 
15 advice elements contained within the "TsTeleaddress" 
object in the order of their containment. 
^ Subsequent to return of the last routing advice 

element and until the next invocation of the reset 
function, the "nextRoutingAdvice () " function returns the 
20 NULL pointer. 

35 

reset : 

void reset () 

40 

Causes the next invocation of the 
"nextRoutingAdvice ()« function to return the first element 
25 of routing advice contained within the "TsTeleaddress" 
45 object. 

routinaAdvice-rni^nh ■ 

si2e_t routingAdviceCount () const 

so ^ 
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Returns the number of elements of routing advice 
currently contained within the "TsTeleaddress" object. 



The "TsTelenarae" class provides a C++ representation 
5 of the Telescript class "Telename", as defined in Appendix 
A of this disclosure. An implementation of the 
"TsTelename" class shall provide, at a minimum, the 
following functionality, 
class TsTelename 
10 { _ 

20 pxiblic: 

TsTelename (TsOctets * authority, TsOctets * 
identity) ; -TsTelename {) ; 

const TsOctets * getAuthority () const; 
15 const TsOctets * getldentity () const ; 

}; 



10 



IS 
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Construction 

TsTelename ; 

TsTelename (TsOctets * authority, TsOctets * 
20 identity) 

Constructs a new "TsTelename" object, 

ftuthoriny 

A pointer to an octet string that is to form the 
authority value of the new "TsTelename" object. 



25 identity 

Either a pointer to an octet string that is to form 
the identity value of the new "TsTelename" object, or the 
NULL pointer if the "TsTelename" object is to contain no 
so identity value. 
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Destruction 

"TsTelename! 
^TsTelename 0 

Destroys the "TsTelename- object. The "TsTelename" 
5 object and all data for which the object has ownership 
responsibility are destroyed. 

Data Acc^^s 

aetAuthority: 

const TsOctets * getAuthority () const 

10 Returns a pointer to the authority value contained 

within the "TsTelename" object. 

aetldentitv; 

const TsOctets * get Identity () const 

Returns either a pointer to the identity value 
15 contained within the "TsTelename" object, or NULL if the 
"TsTelename" object contains no identity value. 



7.1fl TsTelenumt^^y 
35 The "TsTelenumber" class provides a C++ 

representation of the Telescript class "Telenumber", as 
20 defined in Appendix A of this disclosure. An 

implementation of the "TsTelenumber " class shall provide, 
at a minimum, the following functionality, 
class TsTelenuraber 

{ 

25 public: 

TsTelenumber {TsString ♦ country, TsString ♦ 
telephone, TsString * extension) ; 

-TsTelenumber () ; 

const TsString * getCountry {) const; 
const TsString * getTelephone () const; 
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const TsString * getExtension {) const; 

}; 

Constructinn 

TsTele number: 
5 TsTelenumber (TsString * country, TsString * 

telephone, TsString * extension) 

Constructs a new "TsTelenumber" object. 



gpuntry 

Either a pointer to a "TsString" object that is to 
10 form the country code value of new "TsTelenumber" object, 
or the NULL pointer if the "TsTelenumber" object is to 
contain no country code value. 

lisatfi.: The value contained within the provided 
25 "TsString" object is restricted to the set 

numerical codes that CCITT assigns to 
countries or other geographical areas. 



Either a pointer to a "TsString" object that is to 
form the telephone number value of the new "TsTelenumber" 
20 object, or the NULL pointer if the "TsTelenumber" object 
is to contain no telephone number value. 
Note: The characters that form the value contained 

within the provided "TsString" object are 
restricted to the numerals ("0"-"9"), the hyphen 
character ("-") and the space character (" ") . 

Either a pointer to a "TsString" object that is to 
form the extension number value of the new "TsTelenumber- 
object, or the NULL pointer if the "TsTelenumber" object 
30 is to contain no extension number value. 
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The characters that form the value contained 
within the provided "TsString" object are 
restricted to the numerals ("0"-"9"), the hyphen 
character ( " - " ) and the space character ( " " ) . 

5 De^tm^tiQn 

-TaTelenumber: 
-TsTelenumber () 

15 ' 

Destroys the "TsTelenumber" object. The 
"TsTelenumber" object and all data for which the object 
10 has ownership responsibility are destroyed. 

20 

aetCountry! 

const. TsString * get Country () const 

25 

Returns either a pointer to the country code value of 
15 the "TsTeleaddress" object, or the NULL pointer if the 
^ "TsTeleaddress" object contains no country code value. 

aetTeleohonei 

const TsString * getTelephone () const 

35 

Returns either a pointer to the telephone number 
20 value of the "TsTeleaddress" object, or the NULL pointer 
if the "TsTeleaddress" object contains no telephone number 
^ value . 



Note: 

5 



get Ext ens ion; 

const TsString * getExtension () const 

Returns either a pointer to the extension number 

value of the "TsTeleaddress" object, or the NULL pointer 

if the "TsTeleaddress" object contains no extension number 

value. 
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7.19 TsWay 

The "TsWay" class provides a C++ representation of 
the Telescript class "Way", as defined in Appendix A of 
this disclosure. An implementation of the "TsWay" class 
5 shall provide, at a minimum, the following functionality. 

class TsWay 

{ 

public: 

TsWay (TsTelename * name, 
10 TsMeans * means, 

TsObjSpecif ier * secRegimeld) ; 
-TsWay 0 / 



const TsTelename * getName () const; 
const TsMeans * getMeans () const; 
15 const TsObj Specifier * getSecRegimeld () const; 

}; 

Congl^yyction 
TsWay ; 

TsWay (TsTelename * name, 
20 TsMeans * means, 

TsObj Specifier * secRegimeld) 



Constructs a new "TsWay" object. 
name 

Either a pointer to a "TsTelename" object that is to 
25 form the engine/region telename value of the new "TsWay" 
object, or the NULL pointer if the new "TsWay" object is 
to contain no engine/region telename. 

mgang 

Either a pointer to a "TsMeans" object that is to 
30 form the means value of the new "TsWay" object, or the 
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NULL pointer if the new "TsWay" object is to contain no 
means value . 

secReaimeld 

Either a pointer to a "TsObj Specifier" object that is 
5 to form the security regime identifier value of the new 
"TsWay" object, or the NULL pointer if the new "TsWay« 
object is to contain no security regime identifier value. 

^« Destruction 
-TsWav: 



10 



20 



25 



30 



40 



10 -TsWay () 

Destroys the "TsWay- object. The "TsWay- object and 
all data for which the object has ownership responsibility 
are destroyed. 

Data Access 

15 aetNamet 

const TsTelename * getName () const 



Returns either a pointer to the engine/region 
telename value contained within the "TsWay" object, or the 
35 NULL pointer if the "TsWay" object contains no 

20 engine/region telename. 



qetMeana > 

const TsMeans * getMeans () const 



Returns either a pointer to the means value contained 
^ within the TsWay object, or the NULL pointer if the 

25 "TsWay" object contains no means value. 



50 



aetSecReqim^Tr^; 

const TsObjSpecifier * getSecRegimeld () const 
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Returns either a pointer to the security regime 
identifier value contained within the "TsWay" object 
the NULL pointer if the "TsWay" contains no security 
regime identifier value. 
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APPENDIX D 

Copyright ® General Magic, Inc. 1993. All Rights 
Reserved* 

The following table of contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 

Table of Contents 
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1.1 Permit Changes 

10 1.2 Other Changes 
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2.1 Place-to-place Transfer Model 

2.1.1 Traveled Places 

2.1.2 Shipping Boxes 
15 2.1.3 Opened Objects 

2.1.4 Opened Shipping Boxes 

2.1.5 Parts Boxes 

2.1.6 The Use of Tickets 

2.1.7 The Engine's Role 

20 2.1,8 The Engine's Role in Routing 

2.1.9 Implementing Go 

2.1.10 Implementing Send 

3 TELESCRIPT CLASS OVERVIEWS 

3.1 Place-to-place Transfer Group 

25 3.1.1 Opened 

3.1.2 Opened Shipping Box 

3.1.3 Parts Box 

3.1.4 Shipping Box 

3.1.5 Traveled 

30 4 TELESCRIPT CLASS DETAILS 

4.1 Opened 

4.2 Opened Shipping Box 

4.3 Parts Box 



500 



EP0 634 719 A2 



4.4 Shipping Box 

4 . 5 Traveled 

1 INTRODUCTION 

This appendix describes a mechanism for 
5 place-to-place transfer, broadly construed to include 
object interchange and purgatory. 

This appendix is organized in the manner of Appendix 
A of this disclosure. 

The place-to-place transfer mechanism necessitates 
10 several other changes and additiona to the Instruction Set 
of Appendix A, which are described in the subsections 
below - 

Permit Chang^^ 

Whether «go" or operation "send" succeeds or fail?, 
15 allow operation "entering" to grant an agent an initial 
local permit more permissive than the one the agent 
requested. 

Provided operation "go" or operation "send" fails, 
allow operation "entering" to admit an agent while 

20 granting it an initial local permit less permissive than 
the one the agent requested. 

Add to class "Process" a read-only public instance 
attribute, " regional Permi t " , which is the permit the 
current region grants a process. 

25 Replace the "terminate" operation of a place with a 

new, "changePermit" operation which replaces a process' 
local permit. The operation is performed at the request 
of either the place itself or a peer of the process in 
question. 

iO Add to class "Process" a system instance operation, 

" permi tChanged", which the Engine requests whenever a 
place changes an occupant's local permit, e.g., as 
operation "entering" does above, or to eject the occupant 
with or without a grace period. 
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permit: Changed : 

op ( ) Permit Changed | Nil ? 

Requested whenever the responder's local permit is 
changed e,g., by the place the responder is entering, or 
5 occupies already, either to add capabilities or to remove 
them. If the operation's result is an exception, rather 
than a nil, the Engine throws the exception in the 
responder's thread of execution. 

The method for this operation that is native to class 
10 "Process" simply returns a nil. 

Add to class "Execution Exception* a subclass, 
"PermitChanged", the throwing of which signifies that the 
current process' local permit has been changed. 

PermitChanged. 
15 interface (ExecutionException) = () ; 

liStfi: A process' ability to catch and recover from 

this exception, when the process' new local 
permit is severely restrictive, are limited by 
the rules of process termination. 

20 Other Chanq^« 

Provided operation "go" or operation "send- fails, 
allow an agent to find one or more of its interchanged 
objects missing, as described in the place-to-place 
transfer model. 

25 Allow the "go" or "send" operation to take an agent 

to its destination even if the operation fails, e.g., 
because the destination will not grant the agent the 
permit the agent requested. Furthermore, operation 
"entering" is involved even in this case. 

30 Let the Engine request any feature, predefined or 

user-defined, not just a system feature. A user-defined 
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method for a feature requested by the Engine finds client 
and process to be nils, as if the feature were a system 
feature. 

Add to class "Process" a read-only public instance 
5 attribute, "authenticity", which documents the degree of 
confidence the current region has in a process' purported 
authority. This attribute is defined in § 4.57 of 
Appendix A. 

To class "Process" add a read-only public instance 
10 attribute, "creationTime" , which is the time at which a 
process was created. 

Discard the "brand" attribute of a process, 
lifita: Instead a region can define a subclass of class 

"Permit" and supply an instance thereof as a 
15 process' "regional Permit" attribute. 

2 TELESCRIPT CONCEPTS 

Place-to-DlacQ Transfer Mnd^l 

The Instruction Set realizes the "place-to-place 
transfer model" this section defines. 

20 2.jLul Traveled Plf^r^q 

A "traveled" place is one through which shipping 
boxes are transferred. 



Transfer 

The traveled places to which the Network entrusts a 
25 certain shipping box cooperate to "transfer" the box's 
contents from one place, the "origin" of the shipping box, 
to one or more places, "destinations" of the shipping box. 
A traveled place creates new shipping boxes whenever it 
must transfer the contents of a shipping box in different 
30 directions. 

The transfer of the contents of a shipping box from 
its origin to any one of its destinations proceeds in four 
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steps, the last two of which, i.e. transfer in and 
transfer out, can be repeated within a single transfer. 

Submission 

A transfer begins with a shipping box's "submission" 
5 The traveled place to which the shipping box is first 
transferred in as a consequence is its "source". 

Delivery 

A transfer ends with a shipping box's "delivery". 
The places to which a submitted shipping box is to be 

10 delivered are its "destinations". 

A shipping box's delivery is either "normal" or 
"abnormal". In the first case, the shipping box's 
destinations are as specified at submission, and all 
critical parts of the shipping box's contents are present, 

15 In the second case, the Network may have prescribed 

alternative destinations for the shipping box, and some 
critical parts of the shipping box's contents may be 
absent. An exception explains the abnormality. 

Transfer 

20 A shipping box is "transferred in" to a traveled 

place. The transfer in is a consequence of either the 
shipping box's submission from a place, traveled or 
otherwise, or the shipping box's transfer out from a 
traveled place, different from or the same as the traveled 

25 place to which the shipping box is transferred in. The 
place from which the shipping box comes is the shipping 
box's "previous hop". 

TransfAT- n^^^ 

A shipping box is "transferred out" from a traveled 
30 place. The transfer out has as its consequence either the 
shipping box's transfer in to a traveled place, different 
from or the same as the traveled place from which the 
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Shipping box is transferred out, or the shipping box's 
^ delivery to places, traveled or otherwise. The place or 

places to which the shipping box goes is the shipping 
box's "next hop". 

10 5 2, J,.2 Shipping Box^g 

A "shipping box" is one object that holds another, 
its "contents", and that can be used to transfer that 
object from place to place. 
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Peek 

A traveled place can "peek" at the object that is a 
shipping box's contents, i.e., can get the object's 
attributes, subject to the limitation below. 

A shipping box gets an attribute of the shipping 
box's contents using a protected reference to the 
15 contents. If a user-defined method is involved, the 
method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
Additionally, peeking at an attribute disregards its 
prescribed passage, in every case returning a copy of the 
20 attribute, rather than the original. 



Poke 

A traveled place can "poke" at the object that is a 
shipping box's contents, i.e., can set the object's 
attributes, subject to the limitation below. A traveled 
25 place can do this, however, only if the traveled place is 
suitably privileged. 

A shipping box sets an attribute of the shipping 
box's contents using an unprotected reference to the 
contents. If a user-defined method is involved, the 
30 method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
^ Additionally, poking at an attribute disregards its 
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prescribed passage, in every case using a copy of the 
proposed attribute, rather than the original. 

The privileges alluded, to above are assigned as 
follows. An engine place can set the 
5 "authenticationState" or "regional Permit" attribute, even 
though the Instruction Set defines these attributes as 
read-only. Preemptive settings of the "regionalPermit " 
attribute can dictate the shipping box's abnormal 
delivery. 

10 mLS^: A traveled place cannot request operations of a 

shipping box's contents. 

Re^ 

A traveled place can "rebox" a shipping box, which 
the traveled place does if the shipping box must be 
15 transferred in different directions. The Engine removes 
specified destination tickets from the shipping box, 
replaces them with nils, and reaf fixes them to a new 
shipping box identical in content to the existing one. 



20 



A traveled place can "redirect" a shipping box, which 
the traveled place does if an exception arises during its 
transfer. The Engine affixes the exception to the 
shipping box, removes any nils among the shipping box's 
destination tickets, and can substitute for each remaining 
25 destination ticket a single specified ticket. 

Opened Qb-ii^f;tfi 
An "opened" object is one whose zero or more parts 
can be manipulated. 

30 Each "part" of an object, opened or not, is an 

interchanged object whose digest is not a nil. A part of 
an opened object can be replaced with another object of 
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the part's class and digest without materially affecting 
the opened object. 

Presence 

Each part of an object, opened or not is either 
5 "present" or absent. The "absence" of a part, in general, 
limits the object's use, but makes the object's 
place-to-place transfer more efficient. If an object 
attempts to use a reference to a part of itself that is 
absent at the time, the Engine throws "Reference Void". 
10 HfiLa: In typical practice, a part of the contents of a 

shipping box is present at the shipping box's 
submission and again at the shipping box's 
delivery, but is absent at some or all of the 
other steps in the shipping box's transfer, as a 
15 performance optimization. 

Criticality 

Each part of an object, opened or not, is either 
critical or non-critical. An object is designed to be 
used even in the absence of one or more of the object's 
20 "non-critical" parts, but not in the absence of any of the 
object's "critical" ones. 

Mot^: The absence of a critical part of an object 

prevents normal delivery of a shipping box 
containing that object, while the absence of a 
25 non-critical part does not, 

NSta: In typical practice, all parts of an object are 

critical everywhere. Occasionally, a part of an 
object is critical only while the object is in a 
certain place^ 

30 Opened g hippino BoyAs 

An "opened shipping box" is one whose parts can be 
manipulated. The parts of an opened shipping box are 
those of the shipping box's contents. 
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parts Bq\^S} 

A "parts box" is an opened object whose parts can be 
specified explicitly and arbitrarily. Parts boxes serve 
the following four purposes. 

5 Manipul ating Part, a 

The parts of an opened object are manipulated by 
means of parts boxes. This ensures that the parts are not 
directly accessible to the object doing the manipulation. 
The parts in a parts box, e.g., can be included in an 
10 opened object, and specified parts of an opened object can 
be copied or moved into a parts box. The parts themselves 
cannot be examined, even while in the parts box. 
NQ£:£: This protects the intellectual property 

represented by interchanged objects. 

15 gtQ?rj.OT Paartfl 

A traveled place entrusted with opened shipping boxes 
can use a parts box as a repository for parts to be 
included in such shipping boxes. The parts box, a small 
database, serves as a resource in place-to-place transfer. 
20 Hats: This simplifies the implementation of traveled 

places. 

Taking Part^A 

If a shipping box's contents include a parte box, the 
parts box's critical parts are specifically excluded from 
25 the shipping box's parts. Thus the traveled places 
involved in the shipping box's transfer can neither 
examine nor exclude those parts. The optimization that 
such exclusion would represent is not attempted. 
liQta: This enables agents that support place-to-place 

transfer to move interchanged objects between 
traveled places without the system as a whole 
attempting to avoid that movement by the 
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system's (in this case misguided) optimization 
efforts. 

Leaving partr? 

If a shipping box's contents include a parts box, the 
5 part box's non-critical parts are specifically included in 
the shipping box's. In this way, an agent can declare an 
interchanged object non-critical and thereafter take trips 
without that part of necessity accompanying the agent. By 
later removing the part from the parts box, the agent 
10 declares the part critical. Then, if the part is absent, 
either the Engine finds the part locally, or the Engine 
throws "Reference Void" when the agent uses the part. 
NSt£: This enables agents to visit places at which 

certain of their interchanged objects will not 
^« ^se<i without insisting that those objects 
nevertheless be present there. 

The Use of T^,^|rAt-^ 
Tickets define, as detailed below, the places through 
which a shipping box is transferred. Throughout this 
20 section, the "place attributes" are the "destinationName" , 
"destinationAddress", and "destinacionClass" attributes. 
Other ticket attributes that are not mentioned 
specifically below are disregarded. 



25 



A ticket is used to define a shipping box's source. 
The ticket's place attributes, which identify the source, 
are an assigned telename, an assigned teleaddress, and an 
assigned citation, respectively. The ticket's "way- 
attribute, if not a nil, dictates the way in which the 
30 source shall be reached if need be. 
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A ticket is used to define each of a shipping box's 
destinations. The ticket's place attributes identify the 
destination in question. The ticket's "way" attribute, if 
not a nil, dictates the way in which that destination 
5 shall be reached. The "desiredWait" and "maximumWaif 
attributes give the quality of service to be provided the 
shipping box as it is transferred to that destination. 

Previous Hop 

A ticket is used to define a shipping box's previous 
10 hop. The ticket's attributes •destinationName" , 
"destinationAddress" and "destinationclass" , which 
identify the previous hop, are an assigned telenarae, an 
assigned teleaddress, and an assigned citation, 
respectively. The ticket's "way- attribute, if not a nil, 
15 defines the way in which the shipping box was transferred 
in from the previous hop. 

Next Hop 

A ticket is used to define a shipping box's next hop. 
The ticket's place attributes identify the next hop. The 
20 ticket's "way" attribute, if not a nil, dictates the way 
in which the next hop shall be reached. 

2-1. "J The Engin e's RqIp 

Traveled places are properly viewed as facilitating, 
rather than controlling, the transfer of shipping boxes 
25 and their eventual delivery to their destinations. The 
Engine itself is instrumental in this process as follows. 

TransfAT- 

Whenever a traveled place transfers in a shipping 
box, the Engine has already determined whether that 
30 shipping box is an opened one or not. In typical 
practice, the Engine makes this determination 
consistently, not on a box-by-box basis. Thus some 
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traveled places, in general, are entrusted with the 
interchange of parts of the contents of shipping boxes, 
while others are not. 

Tyan^fey Q^K• 

5 Whenever a traveled place transfers out a shipping 

box, "A", the Engine does the following. First, the 
Engine reboxes "A" , moving to a new shipping box, "B", the 
tickets to any destinations to which the Engine can 
deliver shipping boxes. The Engine moves tickets to "B", 
10 however, only if the transfer out is one allowing 

delivery. Second, the Engine reboxes "A" again, moving 
all remaining tickets to another new shipping box, "C". 
Third, the Engine asynchronously transfers "C" and 
attempts to deliver "B" . 

15 Expj^ratipg 

Whenever a traveled place allows any destination 
tickets of a shipping box, "A", to expire, the Engine does 
the following. Such a ticket "expires" when its maximum 
duration is reached. First, the Engine reboxes "A*', 

20 moving the expired tickets to a new shipping box, "B". 
Second, the Engine redirects "B" to a place chosen by the 
Engine, recording "Ticket Expired" as the cause of the 
abnormality. Third, the Engine transfers out "B" to a 
place chosen by the Engine, as if the traveled place had 

25 done so. 

Whenever a traveled place discards a shipping box, 
"A", to which any destination tickets remain affixed, and 
so as to provoke the finalization of "A", the Engine does 
30 the following. First, the Engine reboxes "A", moving all 
destination tickets to a new shipping box, "B". Second, 
the Engine destroys "A". Third, the Engine asynchronously 
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transfers out "B" to a place of the Engine's own choosing, 
as if the traveled place had done so. 

^•^'Q The Engine's Rnlf^ in Routing 

The Engine limits the routes along which a shipping 
5 box is transferred by selecting the shipping box's second 
hop, constraining the shipping box's second -to -last hop, 
and, furthermore, restricting the shipping box's first hop 
in any sequence of hops within a region. 

First Regional Hop 
10 The Engines of a region cooperate to ensure that a 

shipping box entering the region is transferred in at an 
engine place before the shipping box is either transferred 
in at another traveled place in the region or delivered 
within the region. 

15 Second Hop 

The Engine selects as follows a shipping box's second 
hop, i.e., the traveled place at which the shipping box is 
first transferred in from the shipping box's source. 

The second hop is either the shipping box's 
20 submission place, if that is a traveled place, or a 

superplace of the sxibmission place, otherwise. If several 
superplaces are traveled places, the one enclosing none of 
the others is selected. 

Kfita: Thus "submission" can be visualized as causing a 

2^ shipping box to fall through its origin and 

successive superplaces until the shipping box 
reaches a traveled place. 

Second- f o- last Wnp 

The Engine constrains as follows a shipping box's 
30 second-to-last hop, i.e., the traveled place from which 
the shipping box is last transferred out -- to all of the 
shipping box' s destinations . 
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The second-to-last hop is either a destination itself 
or one of its superplaces, this being so for each of the 
shipping box's destinations individually. 
Notg: Thus "delivery" can be visualized as causing a 

5 shipping box to rise through successive 

subplaces until the shipping box reaches one 
qualifying as each destination of the shipping 
box. 

Given the second-to-last hop, if several places 
10 qualify as one of the shipping box's destinations, the 
Engine tries to deliver the shipping box to one of them, 
approaching them in the order defined by section 2.5.4 of 
Appendix A. 

Given the second-to-last hop, if either no places 
15 qualify as one of the shipping box's destinations or none 
of them accepts delivery of the shipping box, the Engine 
transfers out the shipping box to a place of the Engine's 
ovm choosing. 

Non-delivery 

20 An Engine treats the ultimate undeliverability of a 

shipping box as a system error, which the Engine handles 
in accordance with the 0AM policy in force, 
lists: An Engine can provide a place of last resort, 

"Purgatory", for otherwise undeliverable 
shipping boxes. Such a place can severely limit 
an occupant's local permit. 

^'^'2 Implement incf 

The method for "go" native to class "Agent* 
implements the operation as follows using a shipping box 
30 whose contents are the agent and the objects the agent 
owns . 



Submission 
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The Engine creates and submits a shipping box 
containing the agent after validating the agent's request 
for the operation. Thus the shipping box's- first hop, 
i.e., its origin, is the place the agent occupies when the 
5 agent requests the operation. 

Delivery 

The Engine delivers a shipping box by completing the 
operation. Thus the shipping box's last hop, i.e., its 
sole destination, is the place the agent occupies when the 

10 agent completes the operation. 

The operation either succeeds, if both the shipping 
box does not record an exception and only non-critical 
parts of the shipping box's contents are absent, or fails, 
otherwise. If the operation fails, the operation throws 

15 either the exception the shipping box records, if the 

shipping box records one, or an exception of the Engine's 
choos ing , o t herwi se . 



^'^'^0 Implementing Senri 

The method for operation •send" native to class 

20 "Agent" implements that operation in the same way as 
operation "go" is implemented, with two differences. 
First, the shipping box has as many destinations as there 
are clones to be transferred. Second, the contents of the 
shipping box are a representative clone of the agent 

25 requesting the operation. The "identity" attribute of the 
clone's assigned telename is a nil at submission, but is 
set distinctively as each clone is delivered. 



1 TELESCRIPT CIA<?fi n VERVIEWS 

1-1 Place-tO-plagR TT-^T lgfer Group 
30 Object (Referenced) 

• £5LE£a_^22S_ (Opened) 

• Shipping Bqv; ( Unmoved ) 
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• • Opened Shipping Box (Opened) 
5 Opened 

3 >H Opened 
5 Operations 

examine Part a 
excludeParta 

qetNumber 
20 includePartfi 

An "opened" object is one whose parts can be 
manipulated. 

25 

15 An opened object's native operations reveal the 

number (operation "getNumber" ), classes (operation 
"getClasses") , and digests (operation "getDigests" ) of 
3P parts satisfying specified criteria; include new parts 

(operation "includeParts" ) ; exclude existing parts 
20 (operation "excludeParts") ; exclude all existing parts 

satisfying a specified criterion (operation "clearParts") ; 
and arrange for the inspection of specified parts 
(operation "examineParts") . 

^ ■ Opened Shinping Rn-ic; 

An "opened shipping box" is one whose parts can be 
manipulated. 

iuio-i Parts Box 

Operati,on^ 

includePart^ 

A "parts box" is an object whose parts can be both 
specified and manipulated. 



15 
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A parts box's native operation includes new parts 
^ (operation "includeParts") . 

3 ■1-4 Shipping Box 

Attribuhf>,? 
10 5 destinations 

exception 

timfi 

Operations 
10 peek 

rebox 
redirect 
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A "Shipping box" is an object that can be transferred 
25 15 between places, 

A shipping box's native attributes are the time the 
shipping box was submitted (attribute "time"), a ticket to 
the shipping box's source (attribute "source"), tickets to 
the shipping box's destinations (attribute 
20 "destinations"), and any exception encountered in 

transferring the shipping box (attribute "exception"). 

A shipping box's native operations get (operation 
"peek") or set (operation "poke") a specified attribute of 
the shipping box's contents, redirect the shipping box in 
25 case of an exception (operation "redirect"), and rebox the 
40 shipping box to permit several next hops (operation 

"rebox") . 
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3-1.5 Traveled 
Operations 
30 transferOul; 

transferredin 
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A "traveled" object is a place that can transfer 
shipping boxes. 

A traveled place's native operations transfer out a 
shipping box (operation "transf erOut " ) and act upon a 
5 shipping box's transfer in (operation "transferredin") . 

4 TELESCRIPT CIA5S DETAILS 

15 4^ Opened 

Class 

2<> 10 Qpfin^: 

sealed cibstract interface 0 = (...); 
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Public Instance Operations 

unprotected op (isCritical: Boolean|Nil) ; 

15 Removes from the responder and discards all of the 

responder's present parts that satisfy the criterion that 
the boolean (argument "isCritical") prescribes. See 
operation "getClasses" below. 

20 op ( of Class: Class; 

digests: protected Set [Object]) 
PartsBoxjNil ; 



Leaves in the responder and returns the present parts 
^ whose class (argument "of Class") and digests (argument 

25 "digests") are specified. The operation returns either a 
parts box comprising the parts, if there are any, or a 
nil, otherwise. 



50 



excludeParts : 
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unprotected op (of Class: Class; 

digests: protected Set [Object]) 
PartsBox|Nil; 

Excludes from the responder and returns the present 
10 5 parts whose class (argument "of Class") and digests 

(argument "digests") are specified. The operation returns 
either a parts box comprising the parts, if there are any, 
or a nil, otherwise. 

IS 

aetClasaes: 

10 op (isPresent, isCritical: Boolean} Nil) 

^ protected Set [Class] ; 

Returns the classes of the parts of the responder 
that satisfy the criteria defined below that the 
booleans (arguments "isPresent" and "isCritical") 
15 prescribe. 

The first criterion, defined by the first boolean, is 
that the part is either present, if the boolean is true/ 
absent, if it is false; or either, if the argument is a 
nil. The second criterion, defined by the second boolean, 
20 is that the part is either critical, if the boolean is 
true; non-critical, if it is false; or either, if the 
argument is a nil. 
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QetPiaefltfl; 

op (of Class: Class; isPresent, isCritical: 
25 Boolean I Nil) 

protected Set [Object]; 

Returns the digests of the parts of the responder 
that are of the specified class (argument "of Class") and 
that satisfy the criteria see operation "get Classes" 
30 above that the. booleans (argument "isPresent" and 
"isCritical") prescribe. 



55 



518 



BNSDOCID: <EP 0634719A2J_> 



EP0634 719A2 



10 



15 



20 



25 



30 



35 



40 



45 



50 



qetNumb^r; 

op (isPregent, isCritical: Boolean (Nil) Integer; 

Returns the number of parts of the responder that 
satisfy the criteria - see operation "getClasses" above - 
5 -that the booleans ("isPresent- and "isCritical") 
prescribe, 

includePartfi ; 

unprotected op (parts: protected PartsBox) ; 

Includes in the responder the parts of the parts box 
10 (argument "parts") that match, in class and digest, parts 
of the responder. The operation first excludes from the 
responder and discards any matching parts that are present 
there already. 



4^ Opened Shipping any 
15 Object (Referenced) 

• Shipping Box (Unmoved) 

• • Opened Shipping n^y (Opened) 

Class 

Openedflhippir^ryp^^. 

(); 



20 sealed interface (ShippingBox, Opened) 



1^ Parts Bni.^ 

Ob j ect (Referenced) 

• P^yts 9qx ((^ened) 

Clasq 
25 PartsBox t 

sealed interface (Object. Opened) .(.., ) ; 
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initialize : 
unprotected op ( 

criticalParts, noncriticalParts : Set 
5 [Interchanged] |Nil) ; 

Makes the two sets of interchanged objects the 
responder's critical (argument "criticalParts" ) and 
non-critical (argument "noncriticalParts") parts, all 
present initially. If a nil is present instead of a set, 
10 however, the set is presumed cleared. 

20 Public Instance Q nerationa 

"includeParts" : 

unprotected op (parts: protected PartsBox) ; 



10 
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Includes in the responder the parts of the parts box 
15 (argument "parts") , Each part is considered present in 
the responder; each part is considered critical in the 
responder iff the part is so considered in the parts box. 
The operation first excludes from the responder and 
discards any matching parts that are present there 
20 already. 



i-JL Shionincr R^y 

Ob j ect (Referenced) 

* Shipping Bo^ (Unmoved) 

ShippinoBoif; > 

sealed interface (Object, Unmoved) » (..J; 
Construction 

unprotected op () 
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throws FeatureUnavailable; 



5 



10 



Note : 



Throws an exception ("FeatureUnavailable"). 

A shipping box is created by means of operation 
"go" or "send", not using operation "new". 



5 Public Instance At tributes 



readonly protected List [Ticket |Nil] ; 

The tickets that define the responder' s destinations, 
and zero or more nils, which replace tickets moved to 
10 other shipping boxes using operation "rebox"^ 

exception: 

readonly TripException t Nil ; 

Either the trip exception encountered in the course 
of transferring the responder, if indeed a trip exception 
15 was encountered, or a nil, otherwise. 




source : 

readonly protected Ticket; 



35 



The ticket that defines the responder' s source. 



40 



20 



time t 

readonly Time; 



The time at which the responder was submitted. 



45 



Public Instance Qperationg 



50 
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peek : 

op (identifier: Identifier!) copied Object 
throws CopyUnavailable, FeatureUnavailable; 
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Returns the attribute of the responder's contents 
that the identifier (argument "identifier") denotes. 

An exception is thrown if the identifier denotes no 
attribute of the responder's contents that is accessible 
5 to the requester ("FeatureDnavailable") or a copy of the 
attribute is unavailable ( "CopyUnavailable") . 

unprotected op (identifier: Identifiers- 
attribute: copied Object) 
throws Argumentlnvalid, AttributeReadOnly, 
FeatureDnavailable; 



10 



Makes the object (argument -attribute") the attribute 
of the responder's contents that the identifier (argument 
"identifier") denotes. The operation first discards the 
15 attribute if it exists. 

An exception is thrown if the object violates the 
attribute's constraint ("Argumentlnvalid"), the attribute 
is read-only ("AttributeReadOnly), or the identifier 
denotes no attribute of the responder's contents that is 
20 accessible to the requester ( "FeatureUnavailable") . 

unprotected op (tickets: protected Set [Integer]) 

ShippingBox 
throws Poaitionlnvalid; 



25 



30 



Creates and returns a new shipping box whose contents 
are the same as the responder's, and moves to the new 
shipping box the tickets at the specified positions 
("tickets") in the responder's "destinations" attribute, 
replacing them with nils. 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid") . 
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redirect ; 

unprotected op (exception: TripException; 
newDestination: copied Ticket jNil); 

Excludes from the responder's "destinations" 
5 attribute each nil item, replaces each item that remains 
with the ticket (argument "newDestination") iff there is 
one, and makes the exception (argument "exception") the 
responder's "exception" attribute. 

Adapta^ij^ggg 
10 copy 

Throws Copy Unavailable, 

Reboxes the responder as defined by the Model. 
Traveled 

Class 

Traveled: 

abstract interface () « (..,); 



Pyj,vat;g Ipgt;»nc^ QP^r^tigTTia 
20 transferOut! 

unprotected op (shippingBox: unprotected ShippingBox 
40 suggestedNextHop: protected 

Ticket I Nil; 
canDeliver: Boolean) ; 



25 Transfers out the shipping box (argument 

"ShippingBox") to the place either defined by the ticket 
(argument "suggestedNextHop"), if not a nil, or selected 
by the Engine, otherwise. Even if th^ ticket is present, 
the ticket suggests, rather than demands, that the next 
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hop be the place that the ticket defines. The boolean 
(argument "canDeliver" ) indicates whether the Engine is 
free to deliver the shipping box if the Engine is able to 
do so. 

5 sygtern Instance gperfttigpg 

transferredin: 

abstract unprotected op (shippingBox: unprotected 
ShippingBox; 

previousHop; protected Ticket) ; 



10 Requested as the shipping box (argument 

20 "ShippingBox") is transferred in from the place defined by 

the ticket (argument "previousHop") . 



The computer program in Appendix G was compiled and 
linked, in one embodiment, using the UNIX operating system 
15 IRIX 4,0.5, the compiler, and the linker that are provided 

^ with a workstation such as the Iris Indigo* computer 

system available from Silicon Graphics, of Mountain View, 
California. In a second embodiment, the computer program 
in Appendix G was compiled using the MPW C++ compiler, and 

35 20 was linked using the MPW linker, both of which are 
available from Apple Computer, Inc. of Cupertino, 
California and which can be used on an Apple Macintosh® 
computer, which is also available from Apple Computer, 

^ Inc. The particular computer language and the computer 

23 system used are not an essential aspect of this invention. 
In view of this disclosure, those skilled in the art can 

^ implement the invention using a different computer 

language and/or a different computer system. 
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Claims 



1. A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented classes including an agent class and a place class; 
forming instructions for a computer process, said instructions including said object-oriented 
classes, subclasses of said object-oriented dasses. and a go operation; and 
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interpreting said instructions on a processor in said computer network wherein, in response 
to said go operation, an agent process is transported to a place process and further wherein said agent 
process is a member of said agent dass and said place process is a member of said place class. 

5 2. The method for implementing remote programming in a computer network as in Claim 1 further comprising 
forming said go operation within said agent process. 

3. The method for implementing remote programming in a computer network as in Claim 1 further compris- 
ing: 

defining a dass of dass objects; 

forming a dass object, wherein said class object (i) is a member of said dass of class objects, 
and (it) defines a first dass which is a subdass of a selected one of said object-oriented dasses; and 

forming an object, said object being a member of said first dass; 

wherein said agent process owns said object; and transportation of said agent proc- 
ess to said place process comprises transporting said object and said dass object to said place process. 

4. A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented dasses induding an agent class and a place dass; 
forming instructions for a computer process including said object-oriented dasses. sub- 
dasses of said object-oriented dasses, and a send operation; and 

interpreting said instructions on a processor in said computer network wherein, in response 
to said send operation, a done of an agent process is transported to a place process and further wherein 
said clone and said agent process are each a member of said agent dass and said place process is a 
member of said place dass. 

5. The method for implementing remote programming in a computer network as in Claim 4 further comprising 
forming said send operation within said agent process. 

6. The method for implementing remote programming in a computer networic as in Claim 1 . 2, 4 or 5 further 
comprising forming a subplace of said place wherein said subplace Is a member of said place dass and 

30 said place is a superplace of said subplace. 

7. The method for Implementing remote programming In a computer network as In any one of Claims 1. 2 
or 4 to 6 further comprising designating said agent process as an owner of an object 

55 8. The method for implementing remote programming in a computer network as in Claim 7 wherein trans- 
portation of said done comprises transporting a copy of said object to said place process. 

9. The method for implenr>enting remote programming in a computer network as in Claim 7 or 8 further conv 
prising forming within said object a digest 

40 

1 0. The method for implementing remote programming in a computer network as in Claim 9 further comprising 
interchanging for said f irat-mentioned object a second object at said place process wherein said second 
object has a second digest equivalent to said f irat-mentioned digest and further wherein said first object 
is not transported to said place process. 

11. The method for implementrng remote programming in a computer network as In Claim 8 or 9 when ap- 
pended to daim 4, 5 or 6 further comprising interchanging for said copy a second object, which is different 
from said f irst-mentkined object, at said place process wherein said second object has a second digest 
equivalent to said first-mentioned digest and further wherein said copy is not transported to said place 
process. 

12. The method for implementing remote programming in a computer network as in any one of Claims 1 to 
11 further comprising specifying said place process by a ticket nf>ean8. 

13. The method for implementing remote programming in a computer network as in Qaim 12 further conv 
S5 prising forming said ticket means within said agent process. 

14. The method for implementing remote programming in a computer network as in Claim 12 or 13 further 
comprising forming within said ticket means an address of said place process. 
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15. The method for implementing remote programming in a computer network as in Oaim 14 wherein said 
address is a teleaddress 

1 6. The method for Implementing remote programming in a computer network as in any one of Claims 1 2 to 
15 further comprising fomfiing within said ticket means a name of said place process. 

17. The method for implementing remote programming in a computer network as in Qaim 16 wherein said 
name is a telename. 

1 8. The method for implementing remote programming in a computer network as In Claim 4 further wherein, 
in response to saki send operatk>n, a second done of said agent process is transported to a second place 
process wherein said second clone is a member of said agent dass and is distinct from sakJ first- 
mentioned done and further wherein said second place process is a member of said place dass. 

19. The method for implennenting remot^ programming in a computer network as in Qaim 18 further com- 
prising: 

detenmining that transportation of sakJ first done to said first place process and of said sec- 
ond done to said second place process requires transportation of said first and second dones to a single 
computer of a plurality of computers of sard computer network; 

transporting said first done to said single computer; and 

forming, in a single computer, said second done from said first clone. 

20. The method for implementing remote programming In a computer network as in Qaim 19 further com- 
prising: 

transporting said first done from said single computer to said first-mentioned place process; 



2« and 



transporting said second clone from said single computer to said second place process. 



21. A method for Interprocess communication in a computer comprising the steps of: 

defining a plurality of object-oriented dasses induding an agent class; 
30 forming instructtons for a computer process including said object-oriented dasses. sub- 

dasses of said object-oriented dasses, and a meet operation; and 

interpreting sakl instructions on a processor in sakJ computer network wherein, in response 
to said meet operatton, a meeting place process provides a first agent process access to a second agent 
process and provides said second agent process access to said first agent process and further wherein 
35 said first and second agent processes are members of sakj agent dass. 

22. The method for interprocess communication in a computer as in Claim 21 wherein said meeting place proc- 
ess is a member of a place dass in said plurality of object-oriented dasses and further wherein said first 
and second agent processes occupy sakJ meeting place process. 

40 

23. The nnethod for interprocess communication In a computer as in Claim 22 further comprising forming a 
second place process wherein: 

sakj second place process is a member of said place dass; 
said second place process is a subplace of said meeting place process; and 
45 sakj meeting place is a superplace of said second place. 

24. A method for controlling nr)0V6ment of processes in a computer network, said method comprising the steps 
of: 

defining a plurality of object-oriented dasses including an agent dass, a place class, and a 

ticket dass; 

forming a plurality of place processes in said computer network wherein each of said plur- 
ality of place process is a member of said place dass; 

forming an agent process wherein said agent process is a member of said agent class and 
occupies a first place process in said plurality of place processes; and 

forming a ticket wherein said ticket Is a member of said ticket dass and defines a trip in- 
volving the movement of said agent process from said first place process to a second place process in 
said plurality of place processes. 
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25. A method for limiting capabilities of processes in a computer network, said method comprising: 

defining a plurality of object-oriented classes including a process dass and a permit dass; 
forming a process wherein said process is a member of said process class; and 
forming a permit wherein said permit is a member of said permit dass and specifies one or 
more capabilities of said process. 

26. The method as in Claim 25 further comprising: 

defining within said process dass a go operation; and 

spedf ying within said permit whether said process Is capable of performing said go opera- 
tion. 



27. The method as in Qaim 25 or 26 further comprising; 

defining within said process dass a send operation; and 

specifying within said permit whether said process is capable of performing said send 

operation. 

28. The method as in Claim 25, 26 or 27 further comprising: 

defining within said process dass a charge operation; and 

spedf ying within said permit whether said process is capable of perfonming said chaige op- 



20 



eration. 



25 



20. The method as in any one of Claims 25 to 28 further comprising: 

defining within said procese dass a terminate operation; and 

spedfying within saldpenmit whether said process is capable of performing said terminate 

operation. 

30. The method as in any one of Claims 25 to 29 further comprising specifying within said permit whether 
said process is capable of creating a second process, differentfrom said first-mentioned process, wherein 
said second process is a member of said process dass. 

30 31. The method as in any one of Claims 25 to 30 further comprising: 
defining an object-oriented place dass; and 

specifying within said permit whether said process is capable to creating members of said 

place dass. 

35 32. The method as in any one of Claims 25 to 31 further comprising specifying within said permit whether 
said process is restarted upon failure of said process. 

33. The method as in any one of Claims 25 to 32 further comprising spedfying within said pennit an amount 
of processing that is allotted to said process. 
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34. The method as in any one of Claims 25 to 33 further comprising specifying within said pem\t a time at 
which said process is terminated. 

J ■ 

35. The method as in any one of Claims 25 to 34 further comprising: 

defining within said process dass a restrict operation; 

forming instructions for a computer process, said instructions induding said dasses, sub- 
dasses and of said dasses, and said restrict operation; 

interpreting said instructions on a processor In said computer network wherein, in response 
to said restrict operation, a second permit, which is different from said first-mentioned permit, is fbnmed 
and further wherein said second permit is a member of said permit dass and specifies a group of one or 
more capabilities of said one or more capabilities of said process; and 

restricting said process to said group of one or more capabilities specified by said second 

penmit 

36. In a computer, a method of interpreting processes of various versions of an instruction set, said method 
comprising: 

defining a plurality of object-oriented dasses induding a dass of dasses and a class of cit- 
ations; 



527 



BNSDOCIO: <EP, 0634719A2J_> 



EP 0 634 719 A2 



10 



38. 

15 



20 



Classes- ''''' ^^^^^ «~ -"embers of said class of 

p™c«o » . IOC*. I„ o™. of »aM cor»„l«, to z«o or ™„ „^Z^^ *"* 
=.« ».o««y « S» ^oS^™'""- ••»'«'""«•■»■»<>-.». -~«-^o„ P«. ,„ 

moving to said single computer said first done; and «»mputer8. 
forming within said single computer said second clone from said first clone. 

compnsing transporting said first done to said first-mentioned destination place pZL" 

In a computer network tiavlng a plurality of computers, the communication process a^ 
compns.ng transporting said second clone to said second destination place process 

43. In a computer network having a plurality of computers, the communication process as in Qaim 37 f ..^h., 
compnsing spedfying said destination place pn>cess by a name within Z^et meanf 

44. In a computer network having a pluralRy of computers, the communicatten process as in Oaim 37 f urf h«r 
compnsing spedfying said destination place process by an address wZsIS tL« mea^ 

4$. In a computer network having a plurality of computers, the communication process as In Claim 37f urth«, 

nf! P««~»- a name of said destination place process^^d a Son of i 

dassofwhich saw destinatton place process is a member. process, ano a crtation of a 

47. In a computer network having a plurality of computers, the communicatton process as in Qalm 37 further 
comprising specifying, within said tid^et means, a transportetion means wherein L ZspclSton 
means specifies a type of intercomputer communications means by which said doneTtrlZS 

^^^^^"TT"^ '"""'"^ ' "'"'^'"y of computers, the communicatton process as in aaim 37 further 
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49. 



process at said destination place process 

In a computer network having a plurality of computers, the communication process as in Claim 37further 
compnsmgcontrollmg^w^hadestinattonpermitcontainedinsaidticketmeans. operate 
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process is allowed to perform at said destination place process. 

50. In a computer network having a plurality of computers, the communication process as In Claim 37f urther 
comprising controlling, with a destination permit contained in said ticket means, resources that said agent 
process is allowed to consume at said destination place process. 

51. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising specifying, with a destination pemiit contained in said ticket means, a priority for said agent 
process at said destination place process relative to other processes at said destination place process. 

52. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising controlling, via a permit means, a capability that a process is allowed to have. 

53. In a computer network having a plurality of computers, the convnunicatton process as in Claim 52wherein 
said capability comprises a priority for said process relative to other processes. 

54. In a computer network having a plurality of computers, the communicatron process as in Claim 37 wherein 
said agent process owns an object 

55. In a computer network having a plurality of computers, the communicatton process as in Claim 53 wherein 
20 sakl step of transporting a done of said agent process comprises transporting a copy of said object 

56. In a computer network having a plurality of computers, the communicatton process as in Qaim 55 further 
comprising interchanging for said copy a second object at said destinatton place process wherein said 
second object has a digestequivalent to said first-mentioned digest and further wherein said copy is not 

25 transported to said destination place process. 

57. In a computer network having a plurality of computers, the communicatton process as in Claim 54 further 
comprising the step using an interchanged object for said object at said destination place process thereby 
eliminating the need to transpKMl said object to said destination place process. 

30 

58. In a computer network having a plurality of computers, the communicatton process as in Claim 37 wherein 
said transporting step further comprises a step of entering said destination place process, 

59. In a computer network having a plurality of computers, the communication process as in Qaim 37 wherein 
^ said transporting step further comprises a step of exiting said source place process. 

60. In a computer network having a plurality of computers, the communicatton process as in Claim 37 wherein 
said destination place process is a meeting place process and said meeting place arranges a meeting 
between a requestor agent process and a petitioned agent process. 

40 61. In a computer, a communication process comprising: 

providing a first agent process and a second agent process; 

specifying a meeting between said first and second agent processes by a petition means; 

and 

arranging said meeting between said first and second agent processes as defined by said 

46 petitton. 

62. In a computer, the communfcatlon process as in Claim 61 further comprising forming said petition nwans 
within saki first agent process. 

63. In a computer, the communication process as in Claim 61 or 62 wherein said step of specifying a meeting 
comprises specifying within said petitton means said second agent process. 

64. In a computer, the communtoation process as in Claim 63 wherein said step of specifying said second 
agent process comprises specifying, within said petition means, said second agent by a name. 
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65. In a computer, the communtoation process as in Claim 63. wherein said step of specifying said second 
agent process comprises specifying, within said petition means, a class of which said second agent proc- 
ess is a member. 
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66. In a computer, the communication process as in Claim 63 wherein said step of specifying sard second 
agent process comprises specifying, within said petition means, a citation of a dass of which said second 
agent process is a memt>er. 

67. In a computer, the communication process as in Claim 61 wherein said step of specifying a meeting com- 
prises specifying, within said petition means, a maximum time period for arranging said meeting, 

68. In a computer, the communication process as in Qalm 61 wherein said step of arranging said meeting 
comprises providing to said first agent process a reference to said second agent process. 

69. In a computer, the communication process as in Claim 68 wherein said step of arranging said meeting 
further comprises providing to said second agent process a reference to said first agent process. 

70. In a computer, the communication process as in Qaim 81 further comprising causing, in response to an 
instruction within said first agent process, performance of an operation within said second agent process. 

71. In a computer, the communication process as in Claim 70 wherein said first or second agent process owns 
an object 

72. In a computer, the communication process as in Claim 71 further comprising providing to said second or 
to said first agent process respectively a reference to said object, or a reference to a copy of said object 

73. In a computer, the communication process as in Claim 72 wherein said reference is a protected reference. 

74. In a computer network having a plurality of computers, a communication system comprising: 

an agent means having a ticket means and a send operation; and 

a plurality of ptace nrwans wherein each place means is operable in one of said plurality of 

computers; 

wherein said agent means is at a first place means in said plurality of place means; 
said ticket means specifies a trip to said agent means to a destination place means 
in said plurality of place nwans; and 

said send operation transports a clone of sakl agent means to said destination place 

means. 

75. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a second ticket means, different from said first-menttoned ticket 
means, that specifies a second trip to a second destination place means for said agent means. 

76. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
performance of said send operation transports a second done of said agent means to said second des- 
tination place nteans. 

77. In a computer network having a plurality of computers, the communication system as in Qaim 76 wherein: 

saki first-mentioned trip and said second trip both indude transportation to a single com- 
puter in sakl plurality of computer and 

further wherein, in transporting said first-mentioned done to said f Iret-mentioned destina- 
tion place means and said second done to said second destination place means, performance of said 
send operatton: 

(a) transports said first done to said single computer and 

(b) forms said second done from said first done within said single computer, 

78. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a go operation wherein said go operation transports said agent 
means to a third destination place means specified by a third ticket means. 

79. In a computer network having a plurality of computere. the communication system as in Claim 74 wherein 
said ticket means further comprises a name which identifies said destination place means. 

80. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises an address for said destination place means. 
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81. In a computer network having a plurality of computers, the communication process as in Claim 44 or the 
system as in Claim 80 wherein said address is a teleaddress. 

82. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
5 said ticket means further comprises a citation means which specifies a class of which said destinatron 

place means is a member. 

83. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises any combinatton selecting from the group consisting of an address 
of said destinatton place means, a name of said destination place means, and a citation means which 
specifies a class of which said destination place means is a member. 

84. In a computer network having a plurality of computers, the communicatton system as in Claim 74 or proc- 
ess of Qaim 37 wherein said ticket means further comprises means for specifying a maximum time period 
for said trip. 



15 



85. In a computer network having a plurality of computers, the communicatfon system as in Qaim 74 or a 
process of Claim 37 wherein sakj ticket means further comprises means for specifying a desired time 
period for said trip. 

20 86. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
sakl ticket nr^eans further comprises a way means for specifying a type of intercomputer communications 
means by which said trip is to be accomplished. 

87. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
25 sakJ ticket means further comprises a permit means for controlling a deadline for sakl agent means at 

saki destination place nneans. 

88. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
saki ticket means further comprises a permit means for controlling operations that said agent means is 

30 allowed to perform at said destination place means. 

89. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
saki ticket means furthw comprises a permit means for controlling resources that said agent means is 
allowed to consume at saki destination place means. 

35 

90. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
sakl ticket means further comprises a permit means for specifying a priority for saki agent means at said 
destination place means relative to other agent means at saki destination place means. 

91. In a computer network having a plurality of computers, the communication system as in Claim 74 further 
comprising a permit means for controlling a capability that an agent means is allowed to have. 

9Z In a computer network having a plurality of computers, the communicatron system as in Qaim 91 or the 
process as in Claim 52 wherein said permit means is a native penmit 

46 93. In a computer network having a plurality of computers, the communicatkin system as in Qaim 91 or the 
process as in Claim 52 wherein said permit means is a local permit 

94. In a computer network having a plurality of computers, the communlcatton system as In Oaim 91 or the 
process as in Claim 52 wherein said permit means is a temporary permit 
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95. In a computer network having a plurality of computers, the communicatton system as in Claim 91 or the 
process as In Claim 52 wherein saki capability comprises resources that said agent means of Claim 91 
or said process of Qalm 52 respectively can consume. 

96. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as In Qaim 52 wherein sakl capability comprises a deadline after which the agent means of Claim 
91 or the process of Claim 52 respectively cannot proceed. 
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97. In a computer network having a plurality of computers, the communication system as in Claim 91 further 
comprising other agent means wherein said capability comprises a priority for said agent means relative 
to said other agent means. 

5 98. In a computer network having a plurality of computers, the communication system as in Qaim 91 or the 
process of Claim 52 wherein said capability comprises penmission for said agent means or said process 
respectively to perform selected operations. 

99. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means owns an object 

100. In a computer network having a plurality of computers, the communication system as in Qaim 99 or the 
process of Gaim 54 wherein said object has a digest 

1 01 . In a computer network having a plurality of computers, the communication system as in Claim 1 00 wherein 
a copy of said object is transported with said done by performance of said send operation. 

1 02. In a computer network having a plurality of computers, the communication system as in Claim 1 01 wherein 
a second object at said destination place means is interchanged for said copy; and 

further wherein said second object has a digest equivalent to said first-mentioned digest 
20 thereby obviating transportation of said copy to said destination place means. 

1 03. In a computer network having a plurality of computere, the communication system as in Claim 1 01 wherein 
said send operation uses an interchanged object for said copy at said destinatton place means thereby 
eliminating the need to transport said copy of said object to saki destination place means. 

25 

1 04. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises means for entering said place means. 

1 05. In a computer network having a plurality of computere. the communication system as in Claim 74 wherein 
said place means further comprises means for exiting said place means. 

1 06. In a computer network having a plurality of computere. the communication system as in Claim 74 wherein 
said place means further comprises meeting place means wherein said meeting place means arranges 
a meeting between a requestor agent means and a responder agent means. 

107. In a computer, a communication system comprising: 
meeting place means having a meet operation wherein said meeting place is a locale for a 

plurality of agent means; 

a petition means; 

a first agent means in said plurality of agent means; and 
a second agent means in said plurality of agent means wherein; 

saW first and second agent means can meet with any of said plurality of agent means; 
sakI petition means specifies a meeting between said f iret and second agent means; 

and 

in response to said meet operation, said meeting place means arranges said meeting. 

108. In a computer, the communication system as claimed in Claim 107 formed by a process according to any 
one of claims 61 to 73. 

109. In a computer, the communication system as in Claim 79 or 108 or the communication process as in Claim 
50 43 or 64 wherein saki name is a telename. 

110. In a computer, the conwnunicatton system as in Qaim 107 further wherein said meet operation provides 
to said first agent means a reference to sakl second agent 

55 111. In a computer, the communication system as in Claim 110 further wherein said meet operation provides 
to said second agent means a reference to said first agent means. 

112. In a computer, the communicatton system as in Claim 107 further wherein said first agent means can 
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cause performance of an operation within said second agent means. 

113. In a computer, the communication system as in Claim 112 wherein at least one of said first agent means 
or said second agent means owns an agent 

5 

114. In a computer, the communication system as in Qaim 1 13 further wherein said first or second agent means 
can provide to said second or first agent means respectively a reference to said object or to a copy of 
said object 

115. In a computer, the communication system as in Claim 114 wherein said reference is a protected reference. 

116. In a computer network having one or more computers, a method for transfenring data from a first engine 
process to a second engine process, said method comprising the steps of: 

(a) providing means for executing one or more agent processes wherein said executing means com- 
prises said first and second engine processes and further wherein each said agent process comprises 
instructions from a computer instruction set and has an execution state; 

(b) providing within said computer instruction set a go instruction wherein said go instruction is con- 
tained within a first agent process executing within said first engine process and further wherein per- 
formance of said go instruction causes: 

(i) suspension of execution of said first agent process by said first engine process; 
^ (ii) representation of said first agent process such that said execution state of said first agent proc- 

ess is preserved; 

(iii) transfer of said representation of said first agent process from said first engine process to said 
second engine process; and 

(iv) resumption of execution of said first agent process by said second engine process; 

(c) causing execution of said agent process by said first engine process, thereby causing performance 
of said go instruction. 

117. The method of Claim 116 wherein said computer instruction set is object-oriented. 

30 118. The method of Claim 117 wherein said plurality of agent processes are objects of said object-oriented 
computer instruction set 

119. The method of Claim 116 further comprising the step of adding data to said first agent process prior to 
causing performance of said go instruction; 

35 wherein said representation of said first agent process includes said data; and 

further wherein transfer of said representation of said first agent process to said second en- 
gine process includes transfer of said data. 

120. The method of Claim 116 wherein said first agent process comprises data representing a message to be 
^ transported from said first engine process to said second engine process; and 

further wherein transfer of said first agent process resulting from execution of said go in- 
struction causes transfer of said data from said first engine process to said second engine process. 

121. The method of Claim 116 wherein said first engine process executes on a first computer and said second 
^ engine process executes on a second computer wherein said f irat and second computere are part of said 

computer network. 

1 22. A method for transferring data from a first engine process to one or more engine processes, said method 
comprising the steps of: 

(a) providing means for executing 9 plurality of agent processes which comprise instructions from a 
computer instruction set wherein said agent process execution means comprises said first and one or 
more engine processes and further wherein each said agent process has an execution state; 

(b) providing within said computer instruction set a send instruction wherein said send instruction is 
contained within a first agent process in said plurality of agent processes and further wherein, execution 
of said send instruction, includes the steps of: 

(i) forming one or more copies of said first agent process wherein said copies preserve and include 
said execution state of said f irat agent process; 

(ii) transferring each of said copies of said f irat agent process from said firat engine process to a 
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respective one of said one or more engine processes; and 

(iii) effectuating execution of each of said copies of said first agent process by said respective one 
of said one or more engine processes so as to simulate the resumed execution of said first agent 
process. 

5 

123. The method of Claim 122 wherein, upon a condition wherein two or more of said copies of said first agent 
process are to t)e transferred from said first engine process to a single second engine process, the transfer 
of said two or nrare copies of said first agent process comprises the steps of: 

transferring to said second engine process a single copy of said first agent process; and 
10 forming within said second engine process from said single copy said two or more copies 

of said first agent process. 

124. A method of transferring data from a first agent process which is executing within a computer system to 
a second agent process which is executing within said computer system wherein said first and second 

^5 agent processes are occupants of a place process, said method comprising the steps of: 

causing. In response to a meet instruction issued by said first agent process, execution of 
a procedure by said second agent process wherein said procedure is a portion of said second agent proc- 
ess and comprises a collection of computer instructions contained within said second agent computer 
process; and 

20 providing to said first agent process, in response to a second instruction which is issued by 

said second agent process and which is part of said procedure, means for accessing said second agent 
process. 

125. The method of Qaim 124 wherein said step of causing execution of a procedure by said second agent 
process comprises: 

causing, in response to said meet instruction issued by said first agent process, execution 
of a second procedure by said place process wherein execution of said second procedure by said place 
process Issues an instruction which causes said second agent process to execute said first-mentioned 
procedure. 

^ 126. The nrothod of Claim 124 wherein said means for accessing said second agent process is provided to 
said first agent process by said place process. 

1 27. The method of Claim 1 26 wherein, at approximately the time said place process provides to said first agent 
process said means for accessing said second agent process, said place process provides to said second 

^ agent process means for accessing said first agent process. 

128. A method for transferring a first computer process from a firet computer system to a second computer 
system, said fIret computer system comprising a first CPU and a first menrwry and said second computer 
system comprising a second CPU and a second memory, said method comprising: 

^ initiating execution of said first computer process within said first CPU wherein said com- 

puter process has an execution state; 

suspending execution of said firet computer process within said firet CPU; 
representing said firet computer process as data in said firet memory wherein said data in- 
cludes said execution state of said first computer process at the time execution of said first computer proc- 
45 ess is suspended; 

transferring said data from said first memory to said second menwry; 
forming a second computer process on said second computer system from said data wherein 
said second computer process has said state of execution represented in said data; and 

causing execution of said second computer process, thereby effectively simulating resump- 
50 tion of execution of said firet computer process within said second CPU. 
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